I mentioned this in the next Zen table thread, but I have a friend who is going to be out of comission for a few months minimum for health reasons, and want to give him and his family a Zen XY table. My friend would probably be okay with it, but I don’t see his wife being so technical about using it.
With the new build this puts the possibility of having one in a completely non-technical household to the fore. The problem (as I see it ) is software.
Some of the things bandied about in that thread I think are possible, some is just a matter of working out details.
So, I was thinking take a Raspberry Pi, and use GPIO pins to add some “consumer grade” hardware interface. Something that you can give to that luddite uncle who still manages to hold out on getting a smartphone. Probably this could all be done with an Arduino as well, but that required things that I don’t know how to do myself.
So a few things that I’ve been thinking as possibilities:
Rotary encoders connected to pulleys, say at the end of the table opposite the motors to monitor the belts. This, combined with the endstop switches should allow the Pi to calculate the current X/Y coordinates of the ball. This could then be used to coordinate lighting with the ball position. Maybe not easy, but doable. Where the belts cross in the back there, each one will move exactly in time with one of the motors, so this could be used to give feedback to the Pi on precisely what the motors have been doing. It would also require a signal from the endstops for homing. Maybe connect the endstops to the Pi instead, and signal the control board from extra GPIO pins instead? I guess that’s risky if the Pi doesn’t boot correctly.
A joystick, or directional buttons for “etch-a-sketch” mode. Let the user directly draw in the sand. (Extra option, two rotary encoders that directly correspond to the two CoreXY motors for true Etch-a-sketch coordination fun, or could be done as X/Y motion. This pretty much requires that you keep track of the position of the ball, of course… Actually, the idea of “Etch-a-sketch” mode amuses me greatly.
Erase Table button. Keep a simple wiper pattern somewhere, and play it back on a button press.
Default Playlist – play in sequence all patterns stored in a default playlist directory.
Shuffle Playlist – play in random order all patterns stored in default playlist directory.
Of course, all this can be replicated in a web UI as well. With positional data from the encoders, you can also show a graphical representation of the path of the ball for as long as you cared to track it. I might do something like track it’s position for the last so many minutes.
One of the weaknesses of something like Octoprint as a UI for a Zen table is that it depends on position reporting from Marlin, which of course isn’t timely. It generally reports the table position as it is currently commanded, which is not where it actually is. Getting the “real world” position of the table would allow more real-time joystick control by sending a small feed command to the table, and then waiting until it’s actually getting near the commanded position before sending the next move command, so the joystick commands never get way ahead of the table and you have to wait for the buffer.
Of course, I’ve never looked for that precise information from a rotary encoder before, usually just looking for “is it moving”
Basically at this point, what I’m looking for is a gcode sender, and some simple management. The buttons for playlist and table wiping are certainly easy enough to implement. Joystick mode could make some educated guesses as to how long the table will take to process the previous move command before sending the next one based on joystick position. I’d like it to be able to move smoothly and reasonably rapidly, but stop in a timely manner when the joystick is released.
I guess I’m going to have to play with a Pi for a bit and see what I can do. In the meantime, I’m still getting the table ready to depart.