Good new / bad news. The good news is that my new controller for my Taig Mill, based on Arduino Due/gShield running g2core and Raspberry Pi Zero W running spjs, drives the mill 2x faster than the old Mach3 parallel port controller, using the same steppers.
The bad news is that trying to run it from a tablet or a phone with chilipeppr is an exercise in frustration. The full-up tinyg workspace is much too busy for a small screen, and the tinygtablet workspace, while a little better, is still virtually unusable. I experienced the following problems and more:
- Touching a button results in inconsistent behavior. Sometimes the button activates, other times it zooms in and you have to touch the zoomed image, sometimes the tooltip pops up (and often cannot easily be dismissed).
- Gestures in an area (e.g. the jog pane) sometimes result in panning the entire screen. Multitouch gestures, e.g. to zoom in, are very inconsistent due to the many different widget areas. It is pretty scary to accidentally press a button when you were trying to zoom to see something.
- Panning is really hard to control because some pan gestures move the entire screen while others scroll within a widget. Figuring out where to touch to move what you want can be very difficult.
- Auto-resizing widgets like the serial console can play havoc with the screen view
- the browser (especially Chrome on iPhone) often crashes
- Response to the Feedhold button is inconsistent and sometimes delayed. It can be hard to tell if you actually succeeded in touching it. And if you touch it twice, the second touch can sometimes be interpreted as a resume - not good if you are trying to stop an impending machine crash.
- On some setups the “type a number in the DRO field to go to that coordinate” does not work at all. You can type the number in the soft keyboard, but when you exit the keyboard with the NEXT butter (there is no ENTER), nothing happens.
- Toggle buttons like the “filter” one in the serial console are hard to control. Touching them often brings up a tooltip that then obscures the button. The change in button highlight that tells you its state does not show up until you have managed to dismiss the tooltip, so you can’t really tell whether you have toggled it until much later.
- Sometimes the screen just freezes and you have to kill the browser and restart. This happened in particular when I was trying to use the mouse jog pane in the xyz widget.
The bottom line is that the current CP setup is way too complex for controlling an expensive and possibly dangerous machine from a small screen. It mostly works on a big screen with a mouse to point at tiny buttons, but even there the complexity is pushing the limit.
This calls into question the use of the bootstrap.js framework. The idea of bootstrap, of course, is to let you design one UI that will automatically work on different devices. What I have found, though, is for something this complex, the “responsiveness” of dynamically-arranged UI elements completely destroys the usability.
There is a reason why “real” machine controllers have relatively-simple static-layout screens with big buttons. I would like to implement something like that using the CP toolkit, but I’m at a bit of a loss trying to figure out how to separate the core functionality from the many layers of dynamic UI featurism.
