Firmware functionality

[terjeio]

I now have firmware up and running for the new Pi Pico board with more than 30 key functions mapped and support for both I2C and UART mode communication with the controller.

The simplest MPG that can be built would be one encoder for jogging, two buttons, four LEDs and no display. One button for switching MPG mode on/off and one for selecting the axis controlled by the encoder. One LED for indicating MPG mode active and one for each axis to show which axis is currently controller by the encoder.

The most advanced would be a full 5x5 set of buttons, two encoders (one is for navigating the menus etc.) a display and eigth LEDs.

What kind of functionality are you looking for? Buttons for jogging? Buttons for overrides?

[terjeio]

Keys/buttons are wired in a 5 x 5 matrix for a total of max. 25 keys.

Two key rollover is supported meaning that two keys can be pressed at the same time to generate a new key character. This is used to allow jogging in two directions at the same time and for selecting override step size (10% or 1% depending on the Shift key beeing pressed).

Long keypresses are used for functions that should not be easily triggered such as homing the machine. A short keypress will trigger the most frequently used function, a long (> 1s) the more seldom used.
An example is the X lock toggle, X<0> key - a short keypress will lock the axis position while the MPG encoder is turned, another will unlock it. This can be used to calibrate the encoder dial with the axis display, convenient when one turn equals one millimeter movement. A long keypress will zero the X axis.

A keymapping proposal:

// Keytype_LongPress generates the lower case version of the character on a short keypress, uppercase on a long keypress.
// Keytype_Persistent keeps the strobe pin low as long as the key is pressed.

const key_t keyMap[] = {
    {'A',  Keytype_LongPress,   0b0000100001}, // X lock toggle, X<0>
    {'F',  Keytype_Persistent,  0b0000100010}, // Jog Y+
    {'G',  Keytype_LongPress,   0b0000100100}, // Y lock toggle, Y<0>
    {'U',  Keytype_Persistent,  0b0000101000}, // Jog Z+
    {'\r', Keytype_SingleEvent, 0b0000110000}, // MPG mode toggle

    {'L',  Keytype_Persistent,  0b0001000001}, // Jog X-
    {'H',  Keytype_LongPress,   0b0001000010}, // Jog mode toggle (step, slow, fast), Home
    {'R',  Keytype_Persistent,  0b0001000100}, // Jog X+
    {'E',  Keytype_LongPress,   0b0001001000}, // Z lock toggle, Z<0>
    {'~',  Keytype_SingleEvent, 0b0001010000}, // Cycle Start

    {'M',  Keytype_SingleEvent, 0b0010000001}, // Mist coolant toogle
    {'B',  Keytype_Persistent,  0b0010000010}, // Jog Y-
    {'C',  Keytype_SingleEvent, 0b0010000100}, // Flood coolant toogle
    {'D',  Keytype_Persistent,  0b0010001000}, // Jog Z-
    {'!',  Keytype_SingleEvent, 0b0010010000}, // Feed hold

    {'m',  Keytype_SingleEvent, 0b0100000001}, // X MPG scale factor toggle
    {'n',  Keytype_SingleEvent, 0b0100000010}, // Y MPG scale factor toggle
    {'o',  Keytype_SingleEvent, 0b0100000100}, // Z MPG scale factor toggle
    {'T',  Keytype_SingleEvent, 0b0100001000}, // Toggle MPG axis (X, Y, Z)
    {'s',  Keytype_SingleEvent, 0b0100010000}, // Spindle on/off toogle

    {'I',  Keytype_LongPress,   0b1000000001}, // Feed rate override +10%, feed rate override reset
    {'j',  Keytype_SingleEvent, 0b1000000010}, // Feed rate override -10%
    {'K',  Keytype_LongPress,   0b1000000100}, // Spindle RPM override +10%, spindle RPM override reset
    {'z',  Keytype_SingleEvent, 0b1000001000}, // Spindle RPM override -10%
    {0xFF, Keytype_SingleEvent, 0b1000010000}, // Shift
// two key rollover codes
    {'r',  Keytype_Persistent,  0b0001000100|0b0000100010}, // R + F: Jog X+Y+
    {'q',  Keytype_Persistent,  0b0001000100|0b0010000010}, // R + B: Jog X+Y-
    {'s',  Keytype_Persistent,  0b0001000001|0b0000100010}, // L + F: Jog X-Y+
    {'t',  Keytype_Persistent,  0b0001000001|0b0010000010}, // L + B: Jog X-Y-
    {'w',  Keytype_Persistent,  0b0001000100|0b0000101000}, // R + U: Jog X+Z+
    {'v',  Keytype_Persistent,  0b0001000100|0b0010001000}, // R + D: Jog X+Z-
    {'u',  Keytype_Persistent,  0b0001000001|0b0000101000}, // L + U: Jog X-Z+
    {'x',  Keytype_Persistent,  0b0001000001|0b0010001000}, // L + D: Jog X-Z-
    {0x93, Keytype_SingleEvent,  0b1000010000|0b1000000001}, // Shift + I: Feed rate override +1%
    {0x94, Keytype_SingleEvent,  0b1000010000|0b1000000010}, // Shift + j: Feed rate override -1%
    {0x9C, Keytype_SingleEvent,  0b1000010000|0b1000000100}, // Shift + K: Spindle RPM override +1%
    {0x9D, Keytype_SingleEvent,  0b1000010000|0b1000001000}, // Shift + z: Spindle RPM override -1%
};

[carneeki]

Looking good!

My dream pendant would probably want the following functions (I note you have many in the keyMap array)

• Job selection (Gcode file selection; easy navigation of an SDcard with a few folders for each job, and a few files per folder)
• Job control (Cycle start / feed hold)
• Spindle override (during a running job, pressing this and the MPG adjusts the override; during jogging, it can be used to set the spindle speed)
• Feed override (same as spindle override)
• 1 button per axis for the MPG; I'd put each button next to the XYZ on axis on the DRO)
• Easy zeroing an axis / probe control with G38.x. A probe canvas with a few options:
  • Probe up to contact (XYZ moves in positive direction)
  • Probe down to contact (XYZ moves in negative direction)
  • Half value (this is useful for finding the centre of a hole, probe up to edge on X, zero, probe down to edge on axis, and half the value of the current axis, repeat for Y, maybe this could be implemented as a set of probing ops issued to the controller)
  • I understand there are also G38.x options to probe until contact is broken, but I've never used them and cannot see a use case but supporting it may not be a bad idea anyway.
• Coolant toggle
• ``XY "powerfeed" (move axis positive / negative until button press to stop) Implemented via latching switches in parallel with momentary jog buttons.
• Macro / program record menu, IIRC universal G-Code sender has something similar See grblHAL
  • This would permit writing small canned cycles stored within the pendant rather than within grbl (though I understand grblHAL has canned cycle support so perhaps this is unnecessary? I need to check out that project)
  • Permit reading + running the same list of canned cycles.

Mostly my mill has sat idle because I don't want to start a computer for simple jobs like drilling a few holes and milling slots. I was seriously considering removing the steppers and returning it to a manual machine but having a pendant might let me have the best of both worlds.

[terjeio]

Job selection is on my todo list - it might be possible to free up enough pins to add a interface to the board. Many grblHAL drivers/boards has a SD card interface so not needed for them

Easy zeroing is already available already via long keypresses, X<0> etc... I need to add one for zeriong all.

Probing can be added via alternative screens selectable from menus.

XYZ powerfeed is available via jog keys - until the keys are released.

grblHAL has support for many canned cycles, and macros too via a plugin. The macros are triggered via input pins but could be triggered via character commands as well.

The current code has a minimalistic sender that can be called up from screens (or canvases as I call them). There is a multi canvas implementation for threading that can be used as a template for both how to do data entry and how to interact with the sender.

[carneeki]

Sweet! This is fantastic!

Regarding the SDcard, many LCD panels that do SPI also have an SDcard interface too. Streaming from SDcard out the serial port to GRBL might be a good way to do it as then the active running (and upcoming) GCode can be on the display panel like on other control systems. That might be for a job control canvas which has a window in it. It may also update too fast for many displays to handle, depends a bit on the display and driver I suppose. One such combined board (which uses the ILI9341) is http://www.lcdwiki.com/3.2inch_SPI_Module_ILI9341_SKU:MSP3218

For others wishing to do powerfeed like on manual milling machines (which is 'hands off') is, in addition to momentary jog switches, to use latching push button switches in parallel with the momentary switches - this means no software changes are needed.

[andrewmarles]

This is what I'm bringing up just now. Pretty basic, just buttons+neopixels to allow color coding and event responses (TBD). Small screen to show status and UI prompts. Enclosure/buttons are easy to 3d print (clear PETG makes a good light-pipe) so that things are accessible and easy for me to share around. Uses a Pi Pico module on the reverse side. Right now it uses the PCA9615/QWIIC differential I2C interface that is on the Hal2000 boards, but parts shortage makes that problematic going forward so I am likely going to have a version using something else, either optos or maybe I can find a 5V buffered extender that is more available.

Currently just running fairly hacky code to get things working, it basically just emulates the I2C keypad to GRBLHAL and sends the keystrokes. Not sure exactly how this slots into what you're working on, but probably isn't too bad for me to port any of your software over to it which would be awesome.

[terjeio]

At least the grbl response parser could be useful for you, it should be called regularly from the main loop and deliveres data on changes via a callback.

FYI the keypad plugin supports UART mode as an alternative to communication via I2C in the latest versions of grblHAL. UART mode is needed for getting data from the controller such as real-time reports.

[andrewmarles]

For what it's worth, I've been playing around with sending data from real-time reports and state changes over I2C by subscribing to the functions in the keypad plugin. I also have a command that the pendant can use to request a report. I'm not sending the full string in order to save some bandwidth as I mainly just want to be able to reflect the machine states as well as display override settings.

https://github.com/Expatria-Technologies/Plugin_I2C_keypad/blob/Interactive_Jog/keypad.c

[andrewmarles]

Quick vid showing it getting the real-time state changes and overrides etc.

https://youtu.be/kpZH9NzIzzk

[terjeio]

I have finally received the TSSOP adaptor, broken, but was able to glue it back together. I have a few MSP430 controllers I can preprogram if anyone is interested.

The Pico firmware needs more polishing, but the basic functionality is getting there - now even with SD Card support (for SD card connected to the controller):

Encoder scrollable list of filenames, run by pressing encoder select. No scrollbar and no directory navigation yet (to be added?), and long filenames has to be truncated in some sensible way. Three dots in the middle? Shapeoko...Pattern.nc?

[runryder912]

**> The simplest MPG that can be built would be one encoder for jogging, two buttons, four LEDs and no display. One button for switching MPG mode on/off and one for selecting the axis controlled by the encoder. One LED for indicating MPG mode active and one for each axis to show which axis is currently controller by the encoder.

**

Is it possible to have start, hold, mode, food, mist, menu, lcd and 1 mpg (with axis selection button)? Possible rotary pot to handle axis switching. If so, where would I go to easy configure this buttons. Would only the Pi Pico breakout board be sufficient for this? I don't want the keypad.

Thanks for the help

[terjeio]

Is it possible to have start, hold, mode, food, mist, menu, lcd and 1 mpg (with axis selection button)? Possible rotary pot to handle axis switching. If so, where would I go to easy configure this buttons.

Possibly, you'll have to at least modify the RP2040 driver code for that.

Would only the Pi Pico breakout board be sufficient for this?

I guess so, to find out modify the schematic or create a new one. If you can fit everything then you should be ok.

[runryder912]

Is it possible to have start, hold, mode, food, mist, menu, lcd and 1 mpg (with axis selection button)? Possible rotary pot to handle axis switching. If so, where would I go to easy configure this buttons.

Possibly, you'll have to at least modify the RP2040 driver code for that.

Would only the Pi Pico breakout board be sufficient for this?

I guess so, to find out modify the schematic or create a new one. If you can fit everything then you should be ok.

To modify the driver code are you referring to driver.h and not driver.c.

After analyzing the schematic, I only see MPG_A and MPG_B, How do did you wire up both x and z hand rotary with only 1 mpg input

Can i use the RxD and TxD pins on the pico cnc MPG & DRO board to connect it directly to my grblhal Teensy 4.1 and send all signals just through that location?

Thanks for all the direction

[terjeio]

To modify the driver code are you referring to driver.h and not driver.c.

Both if you want to be able to remap pins easily, code changes will be in driver.c.

After analyzing the schematic, I only see MPG_A and MPG_B, How do did you wire up both x and z hand rotary with only 1 mpg input

Two hand wheels are currently only supported by the TivaC driver, I might change the board layout to accomodate two for the RP2040 later.

Can i use the RxD and TxD pins on the pico cnc MPG & DRO board to connect it directly to my grblhal Teensy 4.1 and send all signals just through that location?

Yes, this is possible via the keypad plugin in serial mode.

[runryder912]

Ok, I see the keypad plugin and I was able to reference it from the grblhal Teensy 4.1 configuration machine.h.
As for the actual pins to use with zero modification to your code and pcb, Is the SCL_S 22 (P1.6) and SDA_S 23 (P1.7) the pins I would wire the to the (grblhal teensy 4.1 board on pins 0 and 1) on the MSP430 board after doing the keypad_enable to number 2. Are those the pins that start using uart protocol instead of i2c at the time of the keypad uart configuration change.

If I am missing something, can you guide me to see where the UART pins on the MSP430 is located.
I am only asking these question because I'm studying your code to better understand how i can use it effectively do my wiring. I don't write code but studying it helps

[terjeio]

If I am missing something, can you guide me to see where the UART pins on the MSP430 is located.

The MSP430 is communicating keypresses via I2C to the RP2040 - then either via I2C or UART from the RP2040 to the grblHAL controller.
If I understand you correctly you want to signal keypresses by connecting buttons etc. directly to the RP2040, this is possible with code changes and at least the pins used for connecting the RP2040 to the MSP430 can be used. In addition the pins used for I2C comms to the controller can be freed if you use UART mode. Anyway here is the pin configuration for the MSP430 I use:

[runryder912]

Hello, I got the pico and lcd to boot succesfully, I tried connecting the i2c sda_m and sdc_m to the teensy 4.1 to pins 24 and 25 but the lcd doesn't show the iosender information. I didnt change any code. I am just doing a test run with your existing code  Am missing something? Thanks for the help

…

On Fri, Jan 27, 2023, 2:38 AM Terje Io ***@***.***> wrote: If I am missing something, can you guide me to see where the UART pins on the MSP430 is located. The MSP430 is communicating keypresses via I2C to the RP2040 - then either via I2C or UART from the RP2040 to the grblHAL controller. If I understand you correctly you want to signal keypresses by connecting buttons etc. directly to the RP2040, this is possible with code changes and at least the pins used for connecting the RP2040 to the MSP430 can be used. In addition the pins used for I2C comms to the controller can be freed if you use UART mode. Anyway here is the pin configuration for the MSP430 I use: [image: image] <https://user-images.githubusercontent.com/20260062/215032809-656b8e62-485a-456f-b554-d5e9c9b47e71.png> — Reply to this email directly, view it on GitHub <#6 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATQUGEX5HH477UAL4UDUQBLWUN3NVANCNFSM5LPXTLIA> . You are receiving this because you commented.Message ID: <terjeio/GRBL_MPG_DRO_BoosterPack/repo-discussions/6/comments/4794363@ github.com>

[terjeio]

First - I am not notified when a comment is edited, it is better to add a new one when substantially changed.

Am missing something?

The current implementation uses data from the serial port (UART) for the display. The I2C port is only used for sending commands to the Teensy when a sender "owns" the controller. You have to enable MPG mode in the controller for it to deliver the data to the Teensy serial port.

FYI the I2C display protocol developed by @andrewmarles is now part of the keypad plugins and I am currently working on extending it and adding support for it to the MPG & DRO codebase. My plan is to split out the message parser as a separate github project - making it easier to add to third party projects as a submodule. The parser will support both serial and I2C messages, the latter with somewhat limited functionality. When this is completed the display can be updated via I2C. It should not take too long as I have both Tiva and Pico versions on my bench updating the display via I2C messages...

[rwclark]

Seem to be stuck on this screen. using a teensy 4.1 for the Grbl controller using just the UART port to interface with the pendant.we are suppose to use the keypad plugin correct.

Not sure what I am doing wrong here.

Thank you
Robert Clark

[terjeio]

Try with uncommenting this line..

[rwclark]

Thank you.
That helped, also Figured out it needs to be complied in Arduino so MPG could be enabled. Could not find a option in the web builder.
I have not tested it completely.
Do I need to hook up another pin from the MPG_DRO_booster pack to the teensy pin 28?