Mini wannabe datron build

Reading up on using keystrokes i see a number of potential issues.

Gave me a thought. Still have the RP2040 as a usb keyboard, but add a modifier that can alternately send certain key presses out to the mesa. 2 keyboards in one if that makes sense. No modifier, keys map like a regular keyboard (with text written on them for that). Modifier engaged and special functions go to the mesa either single or in a matrix. Modifier On is probably default, and if you need to type etc, you engage it. Would probably want to remove/disable the default axis key mapping to functions if possible.

So the mesa doesn't need to deal with dumb stuff taking pins like qwerty letters. But it can deal in hardware with M functions, Jogging, etc. RP2040 IO is 3.3v, will need a level shifter.

Hmmm.

Hmmm
 

Hmmmmm

 

Oh, correction. the screen is not 7". not sure why i had that stuck in my head. It is 9".... cause i just found they dont sell it anymore, hahaha. they do have a very similar 8" though.

Looks very good! Black base looks better. Have you tried the virtual keyboard? I will show my lathe project. The screen is small 10.1" . In normal operation it is good to have a knob for speed , spindle speed , rapid travel limit , MPEG .. How will you make the keys , will there be a custom board ? How will you control the digital LEDs ?

 

 

Cool!

The keyboard will be a custom pcb that will take cherry switches. The controller is a rp2040 board that will socket in. this will take care of the usb side, as well as "funneling" keystrokes to the mesa.

The LED's are still a mystery as they really need 2 way communication. Torque isnt too hard i think. Read the torque from the drive to the RP2040, translate that into pretty colours on the leds, and trip a pin on the mesa for overload warnings etc and flash leds red etc.

The rest is a bit tricky. if you change mdi mode for example, how does the keyboard know to light that led the right colour. Likewise the override ring. It needs to get that info back from linuxcnc in the form of a number cause all the dial is doing is incrementing.

The global "stale" leds are easier cause they can just be 2 or 3 pins, one for "error", one for "running" and one for "idle" (or maybe a lack of the other 2 means idle). That led is not on the control itself. it is a 50mm long strip i have that will be up high on the door.

I found a new 8" lcd for it. so it got 1 row of keys smaller. I don;t know if i want the lower panel to be smaller though as the key layout is working well.

Pondering haha.

ok, new 8" screen. keyboard is the same, it just extends to the flange which is not a big deal.

 

There is nor enough room really on the top now for the mpg features, so it is a fully separate unit. it is still controlled by the rp2040, so it has no "brain" inside of it.

If anyone is wondering why the size constraints and why its 2 pieces. it is partly cause that's all the width there is on the cabinet, and partly because that's the size that can fit in my vise jaws for milling. I will be using a big plate of scrap 25mm mic6, so that is dictating some things as well.

ihavenofish wrote:

I'm not sure what the multiswitch does for me. I have no switches on the mesa.

As you noted you may run in to issues mapping the dedicated control buttons via keystrokes.

As an alternative you might have a look at hal_input.comp to connect the 'second' keyboard (i.e. the dedicated controls) to HAL functions.  Mapping in HAL (vs. GUI keystrokes) would have an added benefit of not being overwritten if you update LCNC.  I've not used this comp, but it looks promising.

If you do go this route all, I mentioned Multiswitch as it is (to me) one of a family of HAL components intended, I think, to increase (or enhance) the number of functions of simple pushbutton inputs.

Multiswitch could be used to consolidate the axis/increment selection in to a single input.  If you ignore the 'down' input, repeatedly pressing the axis button would cycle through the different axes and then roll-over back to the first.  Same thing for the increments.  And one of the selection 'slots' can be left blank to act as an MPG-disabled setting.

I think we are on the same page. multiswitch on the penda would cycle. on the spindle button it would cycle m3/m5 (or with shift, m5/m5) etc. So the lighter grey lower buttons are "hardware". in the RP2040 you could map whatever keys you want to bypass to hardware. basically all keys go in, and up to 10 maybe can go back out (only so many pins on the rp2040 and we need 20 for kb input and 1 for led's and a few for the torque inputs, alarms, etc).

Latest refinements. Working out how to attach it to the cabinet - I think in the end it will just be on the surface with a gasket and a non precision hole behind it for access/wiring. The back of the panel will be open. so you open the right side cabinet door and have easy access all the terminals and wires. This is basically how the brother panel is. It is basically a cabinet door that opens. Mine's just made of mdf.  

Also been pasting on various UI's at real life scale to see what is readable. The Probe Basic ui is completely unusable on anything smaller than maybe 17". The siemens 808 ui unsurprisingly works well at 8". The 840 ui (in the render) seems optimised for 10".

 

ok, on the topic of pins....

multiswitch might not be ideal for the mpg, not sure now.

Lets use the 4 buttons on the pendant here.

Button 1: sets the axis you want to move.
Button 2: sets the increment the axis moves per encoder count.
Button 3: turns the spindle on and off.
Button 4: turns the coolant on and off.

3 and 4 are duplicates on the main keyboard which I don't think matters here.

Pressing the spindle button will change the state on a multi switch pin. If the spindle is already on, it turns it off and vice versa. M3 to M5 and back. I think this works. The downside is the LED indication could get confused if there was any sort of hiccup. No big deal though.

The coolant it the same. M7/M9. Same led feedback potential glitch, but not important.

Cycling the axis we may have an issue, but I do not fully grasp how this works internally, so maybe it is fine. When the machine starts, the MPG and the Control have no idea what each other has "set" for MPG functions. On a normal MPG the switches are persistent. If X is set, it is hitting that specific pin on the mesa, so linuxcnc KNOWS what the pendant is set to. With multiswitch you are flying blind a bit like using steppers. You need to preset a common default on both, and then hope there are no glitches that send the display out of sync with the control.

So our trade of having 1 pin per function instead of 4 (xyza) is decidedly more unreliable.

There is a middleground though maybe using binary code. 2 pins will get me 4 settings that cant go out of sync. So 2 mesa input pins (and 2 RP2040 output) per axis button.

So lets count up our IO properly.

M3/M5 - 1 pin, multiswitch on mesa. 1 pin on RP2040.
M4/M5 - 1 pin, multiswitch on mesa. 1 pin on RP2040. Uses same KEY as M3 with shift
M7/M9 - 1 pin, multiswitch on mesa. 1 pin on RP2040.

Cycle Start, Cycle Pause, And Cycle Stop. Hypothetically 3 more pins each, BUT, these are already tied to hotkeys, so potentially they do not need to be pins unless there is a reliability reasoning.

MPG wheel - 4 pins for differential correct? Nothing on the RP2040
MPG AXIS - 2 pins on the mesa, 2 pins on the RP2040, one key.
MPG increment - 2 pins on the mesa, 2 pins on the RP2040, one key.

Jog/MDI mode toggle - 1 pin, multiswitch on mesa. 1 pin on RP2040.
Enable would be one pin each too.

The override wheel i assume is really just another mpg. 2 pins each override (spindle and feed) on the mesa will just increment the override up and down. Pressing the encoder push switch would reset back to 100 so that is 1 more pin each. The RP2040 can read this encoder with 2 pins, and the pushbutton is in the key matrix. Then it needs 6 outputs back to the mesa. We do have the potential again for out led's to be wrong in a glitch, but those aren't super important and would get reset often.

The rest i'm not sure yet how they function.

1 - I want something to instigate a tool change. Press tool/magazine, then a number, then enter and it changes tool.
2 - I want to reference the machine. The ways its done on the DDCS is you press home, then the axis + you want to home, and then enter.
3 - Likewise the same for touching off. Zero, axis +, type a number (or zero), and then enter.

Past that we have some other transparent signals.

- Spindle overload error would be a pin on the mesa and rp2040. PLUS a pin on the rp2040 to read from the spindle drive.

We have used up all the basic IO on the rp2040 already here, but we only need a few more. So we need a 16 pin expander. Not a big deal. If we could serialise some of the lesser functions that would be nice, but I feel a $6 expansion of IO is much easier.

We are still pretty wide open for io on the mesa on the the 7i84.

The last thing we need in the middle is a level converter since all my RP2040 IO is 3,3v.