SBC mode on non-pi's

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.

Mentaluproar

@chrishamm on the bottom it says the first 10 pins are on gpiochip0. I switched it in DWC config but it just gave an error 22 this time, so I guess this isn't helping either.

Falcounet

@Mentaluproar What does gpioinfo returns ? If you are lucky enough, the device tree is correctly documented and the pin number will be displayed

Nurgelrot

Working with anything other than a PI make sure you install the gpiod package. This gives you the gpioinfo utility that will list out all the pins whatever chipset you using has access to. And if you are super lucky the maker of your SBC will have them documented mapping to the the PI's heaader. Hardkernel is pretty good about this with the Odroid line of SBC but others vary.

As for the usefulness with current RRF. I'm on the fence. Some things about the way the pi works I like and others just make it more wiring... The one biggest feature I've stumbled onto is leaving the pi on leaves DWC up. This lets me power the main board on and off from a tasmota and the btncmd plugin. Also software updates are easier esp if you want to bounce between stable and unstable... That's about it so far.

Nurgelrot

I just spent 2 day trying to get Le Potato working with RRF - with both the standard Duet3 boards as well as some STM32F4's.

No Dice. The issue isn't the TranferReadyPin thats pretty easy to find and use. Line 79 on /dev/gpiochip1. The real issues is the lack of OS images with working SPI overlays. I was able to get it loaded into the kernel with the Raspian image off the Libre Computers site and their wiringTools package. But was unable to get DuetControlServer to talk over it.

So I give up if anyone else gets it working drop me a note I'd love to know what I was doing wrong.

Falcounet

@Nurgelrot WiringPi uses the sysfs interface. You want to use spidev.

Nurgelrot

@Falcounet yep I got /dev/spidev0.0 /dev/spidev0.1 to show up an got them merged into the current kernel passed in the bufsiz on the grub line options to the kernel cuz the modprobe.d method doesn't work. Just would not talk. Error 19. Maybe I'll get curious in few days and go for another round with it.