Ugh. The early uiFlow firmware way back in version 1.2 (I think) had a dreaded startup beep… it sounded different, but was still annoying. I put in a request years ago and they eventually turned it off by default and then eventually you could control the on/off in the settings. Looks like they brought it back with no way to turn it off ☹️

https://community.m5stack.com/topic/1595/mqtt-subscribes-on-uiflow

What all have you tried and are you using uiFlow or Arduino?

I'm pretty sure they implemented it a while back, as I originally requested it more than a year ago. I haven't tested it recently, but I believe it was working before. Let me do some digging and I'll see what I can come up with.

It's showing on my M5Burner v2.3.0. It's called Pico but has Stamp in the description.

@ganeyvim

Works for me. Tested originally on uiFlow v1.7.8 and also flashed my M5StickCPlus to the latest v1.8.2. Both tone and beep are working quite well. Yours might be hardware related.

@ksprayberry
Sorry! Got your message and then became quite busy. I created a quick GitHub repo here:
https://github.com/bstein2379/m5stack-grbl-uiflow

@desarrollogis, @Mustafaturgut, and @felmue

I have a workaround until @m5stack fixes it on the server side. The error was introduced because of the new Remote+ blocks in v1.8.0. So to fix your old file, open the .m5f file in a text editor and manually edit it. The bottom of the file should look like this, with the Blockly.RemotePlus section being the new code. You should also test your new file in a JSON validator to ensure you have the right syntax (commas in the right place, etc.). You might have code in the modules section if your program uses any modules.

  "Blockly.Remotes": [],
  "Blockly.RemotePlus": [
    {
      "createTime": 1625322052382,
      "name": "M5Remote",
      "dragAndDrop": false,
      "resizable": false,
      "color": "#fff",
      "bgColor": "#0080FF",
      "type": "title",
      "id": "__title"
    }
  ],
  "modules": []
}

I have only done a quick test of this workaround to ensure the file loads on uiFlow web IDE v1.8.0 and that I can also download the new file to my device. Seems okay for now, but there are some additional Blockly deprecation messages in the Chrome developer tools console that concern me.

Edit: looks like someone beat me to it. The workaround was also mentioned here but I didn’t see it.
https://community.m5stack.com/topic/3428/uiflow-1-8-0/2

@mustafaturgut and @felmue

Thanks for the heads up to not give v1.8.0 a try yet. Looking at the Chrome Developer Tools console, this is the error...

TypeError: Cannot read property 'map' of undefined
    at l.openM5F (main.0403ae3b639489d97cfe.js:1)
    at l.M5F_create (main.0403ae3b639489d97cfe.js:1)
    at FileReader.e.onload (main.0403ae3b639489d97cfe.js:1)
    at t.invoke (polyfills.f72bb0aeb8864eb8b3c6.js:1)
    at Object.onInvoke (main.0403ae3b639489d97cfe.js:1)
    at t.invoke (polyfills.f72bb0aeb8864eb8b3c6.js:1)
    at e.runGuarded (polyfills.f72bb0aeb8864eb8b3c6.js:1)
    at FileReader.<anonymous> (polyfills.f72bb0aeb8864eb8b3c6.js:1)

@m5stack please fix and while you are at it, include multiple beta versions to choose from on the uiFlow web IDE to help avoid situations like this.... or do more thorough testing before releasing!

@ksprayberry

I made some progress today using the Faces kit with keyboard module to send grbl control commands (like $) over ESPnow to the other Core with the GRBL module attached to it. It will print on the screen the received command, write the gcode, and print the grbl response from the ATmega328.

I also have some uiFlow blocks configured to read a gcode file from the SD card, line by line, and write each line to the GRBL module. I have one step motor connected to the X axis of the GRBL module and it spins the motor for each gcode line, so something is working so far! I need to order more step motors so I can build out a 3 axis machine.

Not sure if you have the Faces kit or not, but I can post my uiFlow code here tomorrow if you are interested in any of it.

@ksprayberry

Here you go...

Results from the serial monitor after booting and then pressing button A, which sends $ for help:

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:5280
ho 0 tail 12 room 4
load:0x40078000,len:13424
load:0x40080400,len:3568
entry 0x4008063c

       _  __ _               
 _   _(_)/ _| | _____      __
| | | | | |_| |/ _ \ \ /\ / /
| |_| | |  _| | (_) \ V  V / 
 \__,_|_|_| |_|\___/ \_/\_/  

APIKEY: --------

Grbl 0.8c ['$' for help]
ok

$$ (view Grbl settings)
$# (view # parameters)
$G (view parser state)
$N (view startup blocks)
$x=value (save Grbl setting)

Note: I have not been able to connect directly to the module yet (i.e. to type $ for help, $x to set values, etc.). That's why I used button A to send that Gcode command. With the serial monitor (I'm using Terminal on the Mac), you are connecting to the Core (ESP32) and not the ATmega328 on the GRBL module. The Core and GRBL module communicate via i2c at address 0x70 (or 0x71 depending on the dip switch). However, with the blocks m5stack has provided in uiFlow, you can send any command via the Write G-code block. I will continue to experiment, but I would still like to upgrade the module to grbl 1.1 if possible.