Sandypi

As also Jerome said, with the Uno alone is not possible to achieve such a task. You will need a raspberry pi at least to store the drawings and send them to the driver board.

At the moment I’m working on multiple projects and I think I cannot afford another one.
Still, if you want you can try with Sandypi. I’ve made some installation instructions (I tried to keep it as simple as possible) and they worked for other people with only little experience in these things. If you try with that I can for sure help you in any difficulty you will face (here on the forum or on github by opening an issue).

I’m about to release a new version of Sandipy (couple of weeks I hope) that will integrate the functionality you are looking for as well. I will write here on this topic when it’s released.

3 Likes

Thank you for the reply. Are you using Sandipy in this stack to send the gcode over usb to the UNO serial, or is this another method of accomplishing some of what Sandypi does? It didn’t occur to me that I could be using just usb between a pi and my Uno, I thought I’d be using RX/TX serial coms between boards.

The usb route sounds simpler for sure…

Really appreciate the time people take to reply :slight_smile:

1 Like

Thanks for the response Luca, much appreciated. I’ll comb through the instructions again and see if I can get a clearer picture. Regardless I’m diving in shortly so we’ll see how it goes…

b

2 Likes

USB between Pi and Uno is definitely an option. I’m using that connection between CNCjs and my Uno/CNC Shield-based Burly MPCNC.

1 Like

I’ve built my setup and I’m still working on the actual table to cover the mechanics. All is working well, just need to make it look good.
I’ve been using your pi image and changed the storage location of cncjs to the storage location of octoprint. It finds anything I upload using octoprint but, cncjs doesn’t store if I upload through that interface. It will load whatever I upload, just not store. I’m assuming permissions are needed but, not sure the user to grant them to for cncjs to be able to write to that directory.

I’m also going to put sandify on that pi to test out. It’s there a method of directly storing the gcode generated into a location by default on export?

No. Nothing really runs on the server side. Once you npm build it, it is just a static page.

I haven’t tried the watch directory in cncjs. But my impression was that the upload didn’t even try to store the file.

Another option is sftp or scp.

good call. I did not realize that upload did not store at all. The watch directory works for sure. I will try and see if I can get an interface that would allow uploading from cncjs to that watch directory. I figured that the upload meant it would store it somewhere. It has to be putting it somewhere for use. Maybe just memory, i guess. If it is stored in a temp location, I can have a script watch that location and copy the contents over to the watched directory.

I think the watch directory was a bolt on feature, and not part of the core piece.

@texx I am using the pi image from jeff and attempting to install sandypi on it. Have either of you been able to do this? I am not able to run it and have attempte dupdated several things that I thought might be causing it. No luck yet.

error @testing-library/jest-dom@5.11.9: The engine “node” is incompatible with this module. Expected version “>=8”. Got “6.17.1”
error Found incompatible module.
info Visit yarn install | Yarn for documentation about this command.
yarn run v1.22.10
$ react-scripts build
/bin/sh: 1: react-scripts: not found
error Command failed with exit code 127.

I looked into the troubleshooting guide and there is mention of exit code 127 and the suggestion about connectivity. I went into the install.sh and added --unsafe-perm to the yarn commands and that got me through some other errors that were present. These are the last of the errors and I cannot figure it out.

I have not tried that. I do install node for cncjs.

I probably broke something. Going to try all from scratch. I’m trying to put everything on one build if I can. There are probably conflicting dependences. I like the cncjs interface for full control. Octoprint with the better grbl interface is approximate though.

I installed it today for the first time. I am not surprised it collides with the stuff I did. Cncjs would probably work with a newer version of node. Or else, you could install it using docker and probably be pretty satisfied. I installed it on docker on my laptop, but I started with an image with node, yarn, and python already installed and not for arm.

Very slick software though. I am excited to try more.

1 Like

Hi! I didn’ try with that image actually… I was working with the standard raspbian os image (one of the last ones) because the software needs a raspbian buster or newer to run because of some dependencies… I’m not sure what is running jeff on that image but it looks like the node version there is older and incompatible with respect to the one I’m using. @jeffeb3 just created a pull request that should fix the problem but it is not ready for the pi yet. If for the moment you can afford to use a new image with the latest raspbian os version it should work. I will try to fix this problems once for all with docker files if I can but it is something I never used and I need to spend some time on it…

I have started in on docker at one point and did not stick to it. It is something I plan on trying again at some point but, I need a motivated reason for it.

I will go ahead and build out from a fresh install. Then Put octoprint on it as well. I just need a decent control method when not automating everything. Your interface looks great and maybe has everything I would need. I will know later today.

I did install a couple addons for octoprint that seem to work well for the sand table. one is called continuous print. You can queue and repeat indefinitely. It was meant for pushing prints off the plate between prints. I added gcode to move certain ways and home again between just in case.
I just want a clean interface with little thought for end users to be able to start the table. octoprint does not visualize the gcode and that seems to be one of the only downsides of using it as an interface.

I’m not at all into docker but I’m quite sure it will be necessary to link the serial port to the image otherwise the software will not be able to see it.

Thanks for trying it out!
At the moment in the current version of sandypi the only way to run the table continuosly is to create a playlist with a loop element. I’m currently working on something easier and it will be ready in the coming weeks. I’m also planning to add an option to start drawing directly when the board is turned on without the need of connecting…

Please keep me updated with that docker file… If you manage to make it work it will make the installation easier and remove a lot of installation issues for sure. If you want a starting point you may have a look at the docker file jeff wrote. He tried on a linux pc but not on a raspi and he didn’t try to connect to a board.

FWIW, I didn’t write that to solve this problem. But if all you have is a hammer, everything looks like a nail :slight_smile:.

I have some docker images controlling gpio on a pi. I think connecting the serial will be even easier. I think it is just about getting the right/dev/ttyACM0 device with a --dev argument. Sometimes you need to add a privilege, but I don’t think so with serial. It is easier than doing it in a VM.

I just, finally, got the setup working as detailed on the install instructions. After starting from a fresh image and updating. Them I had to run the install script a couple times because it didn’t like something the first time around. Cannot remember what but, it’s working now!
I am running some tests with it and have the raspi touch screen set up with it. Linked to sandify in one tab. The workflow is simple. I might install sandify locally just to make sure a network connection isn’t necessary but, I plan on using it networked.

One thing I noticed right away was that the gcode renders fine but, the window is always square. I generated a path that would show the bounds of the table and it rendered. Was worried it ignored the layout in settings. Great stuff though. I might make a pull out in the table to access the screen.
I like running gcode on connect. That’s useful and I had zero issue connecting and running code right away. I’m using grbl 1.1, I think that’s the latest. Whatever the latest is, I’m running it. Now I just need to figure out how to reduce the sound of belts more. I have some tmc2208 drivers and they are quiet compared to the dev ones but, I still hear robot voices from the motors.
I have an esp32 grbl board I’m going to use eventually. Might try other drivers with that too see if I can reduce the sound more. Maybe try gearing the steppers to combat it. Not sure yet.

On to finishing the wood work. Just cut down and planed a bunch of walnut. Going for a greene and greene/japanese look to match the esthetic.

2 Likes

Nice! It would have been interesting to see where the problem was the first time but at least it worked :wink:

At the moment the preview is really basic… It is just resizing to get the entire drawing in it without taking into account the table shape. I think I will keep it like this (fit the drawing in a square) for the preview. In the future I will change the single drawing page to show the position of the drawing with respect to the table shape/borders

From what I remember, it stated something about the npm version. However, I did a reboot and ran the script again without issue.

The preview is fine. I just thought I would say something in case.

1 Like

Whew! I thought I was the only one they talked to. :crazy_face:

1 Like