Thinking about a "simple" UI for a zen table

ZenXY Software
1

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.

4 Likes
2

Kudos to you for being a good friend and keeping the family in mind. :+1:

1 Like
3

I’ve only quickly skimmed Zen topics as they come across the forum, but it seems to be that some of what you want to do has been mentioned. From my uneducated point of view (and acknowledging that I don’t have a ZenZY machine), a couple of thoughts.

  • With the phrase “completely non-technical household,” I would think of a physical joystick, not an electronic interface. Marlin has an interface for a joystick. Here is a long topic by the person who wrote that interface. You would get smooth movement with the ability to lock out the joystick while the g-code files are being processed…without having to add encoders.

Looking at the Marlin g-code, it seems that the interface to the SD-card-related g-codes would give you all the control you need for a non-technical interface. Something that emulates CD-Player for example.

  • Do a wipe
  • Play next file
  • Play previous file
  • Play specific file
  • Abort current file
  • Random play among a list of files
  • Etc.

While I don’t know much about the Marlin code base, my first thought would be to hack Marlin rather than to add physical encoders if that is the road you go down for your joystick. Brainstorming, adding two g-code that are processed by the emergency parser would give you all the control you need…one to report on how full the queue is, and one to flush the queue. Note that these two g-code would have been helpful in solving some other problems that have come up in the forum.

4

I remember seeing that joystick interface topic before, and while it seemed a good solution for a CNC, it didn’t quite fit what I was thinking of here. Yes, I am thinking of a physical joystick, and that it would be locked out while a file was printing.

Mostly, I was thinking a separate processing box (Pi) rather than hacking Marlin because it would allow a web interface as well, so could be done from a phone or tablet the same as if you were pushing the physical buttons.

I was thinking of making the button board using the spare arcade buttons and such that I have, though the joystick would be a smaller unit, probably analog as well to get various angles. (Though I still think that 2 rotary encoders to emulate an Etch-a-sketch would be awesome in so many ways. Just don’t turn the table upside down and shake it.)

I suppose that pots could be used instead of encoders, if I were to break down the range of positions to 1023 steps, but the pots would end up being very sensitive, and there would be some issue of timing… Someone cranks on the pot, then turns it back, the table isn’t going to keep up, and then we get lag from control to result again… Besides, 2 pots is basically just an analog joystick.

I like the CD player example. Skip forward/back is a good idea, though it might have some weird consequences with what happens on the table. I might need to have some sort of display telling the user what it thinks that it’s doing.

5

You could use digital pots driven by the PI to feed the joystick inputs to Marlin. That way you could also have a web interface. If you can find a way to query Marlin about how full the queue is, then you could also have smooth movement from serial delivered g-code commands. If you hadn’t figure it out, I expect problems with implementing an encoder or potentiometer solution to measure the position, but I don’t have a lot of electronics experience.

6

Kark (@karltinsly) made a neat board that would talk serial to the marlin controller. It was an arduino nano and an sdcard reader. It had a button and a switch. IIRC, it would play all the files in order but pause unless the switch was on, or the button was pressed.

To me, even less technical people can use a website on a phone. You can have much more intuitive controls that way. Good feedback, etc. I think sandipy is on the right track and you should really try that first. It has visualizations of the patterns to play. Adding a control interface there would be easier. Any next, prev, shuffle, pause, play buttons belong in the web, IMO.

@jamiek’s joystick for marlin code uses a pretty good analog joystick. But to me, the real magic is the interface to the planner. It is tricky to get that right. If you send XY that are short and close, you end up with starts and stops. Too long and you can overshoot, and the whole thing lags. Jamie makes small movements just long enough to avoid the acceleration limits. So it ends up pretty smooth. It is worth understanding that code better. I keep thinking marlin would benefit from a different gcode based jogging that would use that same logic.

7

Currently you have to do G90 and G91 to switch between relative and absolute mode and there is no push/pop to restore what was there before, so in the general case it is risky that you might leave it in the wrong mode. One g-code command that could be hacked into Marlin that would help is being able to send relative g-code movements regardless of relative/absolute movements. This would be useful for jogging in general.

Since the joystick modification is hacked into Marlin, it has access to Marlin internals and “cheats” to insert relative movements regardless of machine state.

If this new modified G1 command existed (always using relative mode regardless of G90/G91) then implementing etch-a-sketch or continuous external jogging like a jog wheel from an external source should be relatively straightforward.

8

I was imagining something like:

G0 J1 X10 Y10

For moving at 10mm/s jog in X and Y.

Or maybe

G0 J10 I10

Or

G0 J1.0 I1.0 F848

But I don’t think the precise linear feedrate is as important for jogging.

And I always assume my machine is in absolute. So does sandify :slight_smile:. Maybe that would cause trouble in other situations.