WiFi \ Hard limit error

[normanruta]

Hi,

I was told that this issue might be best to report here. https://openbuilds.com/threads/wifi-hard-limit-error.20157/#post-132866

I'm new as a CNC hobbyist. I have purchased a custom version of Lead 1010 which is as long as model 1515 but wide as 1010. Machine came to with blackbox x32 and I'm using my whole available time to get to know it. During my learning, tests, configurations I have came into a trouble. I have everything configured and machine works as it should however when I'm adding WiFi config it triggers:

A ALARM: 1 - Hard limit triggered. Machine position is likely lost due to sudden and immediate halt. Re-homing is highly recommended. [ undefined ]

And it loops. I can't home, can't move. Only cancel error message but the alarm stays on.

It seems that either I can have hard limits turned on or WiFi. As soon as I delete settings for SSID and PSK the problem goes away.

I have tried to reset blackbox using reset button with or without USB attached but it does not matter. I tried also changing SSID and PSK on my access point and made it as short as possible without special characters but that didn't helped.

Steps: Machine configured and working properly Adding SSID and PSK Allowing for reboot Manually resetting machine with a button WiFi is working and I'm able to connect Alarm is triggered on both USB and WiFi connection Clearing out SSID and PSK Allowing for reboot Manually resetting machine with a button Issue is gone Config below that I'm using is the default for 1515 plus some minor changes for spindle (VFD) and calibration:

$0=10.0 ; Step pulse time, microseconds $1=255 ; Step idle delay, milliseconds $2=0 ; Step pulse invert, mask $3=0 ; Step direction invert, mask $4=0 ; Invert step enable pin, boolean $5=7 ; Invert limit pins, boolean/mask $6=1 ; Invert probe pin, boolean $7=0 ; Disable spindle with 0 speed, boolean $8=0 ; Ganged axes direction invert as bitfield $10=511 ; Status report options, mask $11=0.010 ; Junction deviation, millimeters $12=0.002 ; Arc tolerance, millimeters $13=0 ; Report in inches, boolean $14=0 ; Limit pins invert, mask $15=0 ; Coolant pins invert, mask $16=0 ; Spindle pins invert, mask $17=0 ; Control pins pullup disable, mask $18=0 ; Limit pins pullup disable, mask $19=0 ; Probe pin pullup disable, boolean $20=0 ; Soft limits enable, boolean $21=1 ; Hard limits enable, boolean $22=1 ; Homing cycle enable, boolean (Grbl) / mask (GrblHAL) $23=7 ; Homing direction invert, mask $24=100.0 ; Homing locate feed rate, mm/min $25=2000.0 ; Homing search seek rate, mm/min $26=250 ; Homing switch debounce delay, milliseconds $27=1.000 ; Homing switch pull-off distance, millimeters $28=0.100 ; G73 retract distance, in mm $29=0.0 ; Step pulse delay (ms) $30=24000.000 ; Maximum spindle speed, RPM $31=0.000 ; Minimum spindle speed, RPM $32=0 ; Laser-mode enable, boolean $33=400.0 ; Spindle PWM frequency $34=0.0 ; Spindle off Value $35=0.0 ; Spindle min value $36=100.0 ; Spindle max value $37=0 ; Stepper deenergize mask $39=1 ; Enable printable realtime command characters, boolean $40=0 ; Apply soft limits for jog commands, boolean $43=1 ; Homing passes $44=4 ; Homing cycle 1 $45=3 ; Homing cycle 2 $46=0 ; Homing cycle 3 $62=0 ; Sleep Enable $63=2 ; Feed Hold Actions $64=0 ; Force Init Alarm $65=0 ; Require homing sequence to be executed at startup $70=7 ; Network Services $73=1 ; Wifi Mode $74= ; Wifi network SSID $75= ; Wifi network PSK $100=200.040 ; X-axis steps per millimeter $101=200.000 ; Y-axis steps per millimeter $102=200.770 ; Z-axis steps per millimeter $110=3500.000 ; X-axis maximum rate, mm/min $111=3500.000 ; Y-axis maximum rate, mm/min $112=1000.000 ; Z-axis maximum rate, mm/min $120=350.000 ; X-axis acceleration, mm/sec^2 $121=350.000 ; Y-axis acceleration, mm/sec^2 $122=350.000 ; Z-axis acceleration, mm/sec^2 $130=752.000 ; X-axis maximum travel, millimeters $131=1302.000 ; Y-axis maximum travel, millimeters $132=122.000 ; Z-axis maximum travel, millimeters $300=GRBL ; Hostname $302=192.168.5.1 ; IP Address $303=192.168.5.1 ; Gateway $304=255.255.255.0 ; Netmask $305=23 ; Telnet Port $306=80 ; HTTP Port $307=81 ; Websocket Port $341=0 ; Tool Change Mode $342=30.0 ; Tool Change probing distance $343=25.0 ; Tool Change Locate Feed rate $344=200.0 ; Tool Change Search Seek rate $345=100.0 ; Tool Change Probe Pull Off rate $370=0 ; Invert I/O Port Inputs (mask) $384=0 ; Disable G92 Persistence $I=leadmachine1515

[terjeio]

Which build date of grblHAL? Use $I to find it:

[VER:1.1f.20230227:]

There is a silicon bug in the ESP32 that leads to the radio spuriously triggering GPIO interrupts on some pins. IIRC a workaround was committed not long ago (late last year).

[petervanderwalt]

[EDIT] - included firmware in CONTROL is up to date, but some shipped units come with older firmware. Always update firmware from CONTROL > Wizards and tools > Firmware Flashing tool

Optionally, you can still follow the below to build firmware via Web Builder

[/EDIT]

Our included firmware on BlackBoxes might be older than that for sure, so if there has been commits since, then @normanruta please build a new Build using http://svn.io-engineering.com:8080/?driver=ESP32&board=BlackBox%20X32 (set Y to Ganged, Set SD Card to Enabled on Plugins tab, and set WebUI, Wifi, Telnet, Websocket, HTTP on Networking Tab - to match our usual firmware options) If you grab the WebUI V3 follow https://github.com/grblHAL/Plugin_WebUI/#installation to install it if you want to check it out

[normanruta]

@terjeio

Which build date of grblHAL? Use $I to find it:

[ $I ] [VER:1.1f.20220325:leadmachine1515] [ $I ] [OPT:VNSL2,35,1024,3,0] [ $I ] [NEWOPT:ENUMS,RT+,HOME,TC,SED,WIFI,SD] [ $I ] [FIRMWARE:grblHAL] [ $I ] [NVS STORAGE:*FLASH] [ $I ] [DRIVER:ESP32] [ $I ] [DRIVER VERSION:220327] [ $I ] [DRIVER OPTIONS:v4.3.2-555-gb4ef1b80a2-dirty] [ $I ] [BOARD:BlackBox X32] [ $I ] [AUX IO:1,0,0,0] [ $I ] [WIFI MAC:94:B5:55:30:D8:5C] [ $I ] [IP:0.0.0.0] [ $I ] [PLUGIN:SDCARD v1.05] [ $I ] [PLUGIN:ESP32 WebUI v0.03] [ $I ] ok

[petervanderwalt]

20220325

factory default yes - do see https://github.com/grblHAL/ESP32/issues/61#issuecomment-1448180150

[normanruta]

@petervanderwalt

Thanks for the instructions but I think it is a bit beyond me.

I'm not sure how to do this. Especially these parts:

https://github.com/grblHAL/Plugin_WebUI/#installation https://github.com/grblHAL/core/wiki/Compiling-GrblHAL https://github.com/grblHAL/core/wiki/First-Run-Grbl-Settings

Maybe it will be better if I wait for the official channel and till then stick with USB connection. I don't wanna break things up in my blackbox.

[petervanderwalt]

You really can't break anything - if you do just go to Wizards and Tools > Firmware Flashing tool and flash back the default firmware

https://github.com/grblHAL/core/wiki/Compiling-GrblHAL

You don't do this, see my earlier comment - use the web builder.

https://github.com/grblHAL/core/wiki/First-Run-Grbl-Settings

You also don't do this, you already have settings on the controller. Just flash the firmware

https://github.com/grblHAL/Plugin_WebUI/#installation

Skip it for now - you'll use CONTROL instead of the WebUI most likely anyway

Recap: Web Builder - build new firmware and download the ZIP Extract firmware.bin from the zip and put it somewhere (desktop or wherever) CONTROL > Wizards and Tools > Firmware flashing tool > X32 tab > Machine style: CUSTOM > Click the red Select Custom BIN button > Select the firmware.bin you saved above > Click Flash.

[normanruta]

Thanks for explaining. I flashed the firmware as instructed. Needed to restore my settings but after that machine started to work and it is free from the described issue :) Also the responsiveness over WiFi is better and ping lower than on previous firmware. This is great!

In settings tab I noticed that some values are now with a red tags that looks a bit like so:

I'm guessing that it might be related to the lack of some modules.

Is there anything else I should do?

[terjeio]

In settings tab I noticed that some values are now with a red tags that looks a bit like so:

This is likely due to a change in setting numbers for station mode and the sender having settings information hardcoded.

[normanruta]

Got it. Most likely I'm not gonna need these anyway. Just wanted to be sure that this is fine.

I have build a firmware again using website. This time without HTTP. Not sure if related but now this machine actually fly when I'm using WiFi. Gotta close my windows or I'm gonna wave for a goodbye to this machine ;)

Obviously FTDI underneath USB is much slower but something tells me that unused modules are affecting overall performance too.

Anyway thanks for your help and all the answers!

[petervanderwalt]

Obviously FTDI underneath USB is much slower but something tells me that unused modules are affecting overall performance too.

Not likely, possibly just slightly different Grbl parameters?

[terjeio]

Obviously FTDI underneath USB is much slower

Per default the baud rate is set to 115200, this can be changed but I have not made that option easily available yet. A "native" USB connection or network connection is usually at least an order of magnitude faster - sometimes a lot faster than that.

but something tells me that unused modules are affecting overall performance too.

Most should not affect overall performance in a significant way and likely not for anything else than high speed laser engraving where a lot of very short moves are commanded. I do not have any deep understanding how the low level lwIP networking stuff woks and how much overhead that adds - but have not had any feedback yet that e.g. the http daemon affects performance. If you can shed some light on what you experienced I am all ears.

BTW if commanding a lot of small movements, or arcs, then increasing the planner buffer may have a significant effect on performance. This can now be done by changing the $398 setting and rebooting the controller. Note that increasing this has no or little effect if the sender isn't using the character counting protocol - allowing it to queue up many moves in the serial input buffer. @petervanderwalt FYI the input buffer for most grblHAL configurations is 1024 bytes, compared to 128 bytes for legacy Grbl.

[petervanderwalt]

BTW if commanding a lot of small movements, or arcs, then increasing the planner buffer may have a significant effect on performance. This can now be done by changing the $398 setting and rebooting the controller. Note that increasing this has no or little effect if the sender isn't using the character counting protocol - allowing it to queue up many moves in the serial input buffer. @petervanderwalt FYI the input buffer for most grblHAL configurations is 1024 bytes, compared to 128 bytes for legacy Grbl.

We do use Character Counting, and have https://github.com/OpenBuilds/OpenBuilds-CONTROL/blob/79eb9ff603d1884830a403026bcafd768a9c7514/index.js#L342-L343 var GRBL_RX_BUFFER_SIZE = 127; var GRBLHAL_RX_BUFFER_SIZE = 1023;

in use with our character counting setup https://github.com/OpenBuilds/OpenBuilds-CONTROL/blob/79eb9ff603d1884830a403026bcafd768a9c7514/index.js#L2670-L2683

[terjeio]

var GRBLHAL_RX_BUFFER_SIZE = 1023;

This is a bit dangerous as there are grblHAL controllers out there that has less - to be sure it is best to read the size from the $I response:

[OPT:VNMSL,35,1024,3,0]

This field is present in legacy Grbl, and should be present in other ports too. And yes the actual available size is one byte less.

[petervanderwalt]

We do actually parse out OPT: https://github.com/OpenBuilds/OpenBuilds-CONTROL/blob/79eb9ff603d1884830a403026bcafd768a9c7514/index.js#L1280-L1281 for buffer size - so just has to switch that function to look at that instead of the hardcoded variable - will do that for next release (var-1 of course)

[petervanderwalt]

Done: https://github.com/OpenBuilds/OpenBuilds-CONTROL/commit/426a923c378a41fc1c9dbd2112df61fdf3e22672

[normanruta]

@petervanderwalt

Not likely, possibly just slightly different Grbl parameters?

Parameters were the same. At first tests I have had an acceleration set to 150 then changed it to 350 but when was doing a pocket of a 40mm diameter and 20% step over (lots of g-code line) it was starting each circle quite fast but then slowed down considerably at the second-ish half of it. Acceleration change helped a bit but not by much and the faster the feed was set up the more visible it was. After firmware change I can set 3000mm/min and whole circle is being done with that speed. That being said I also started to use WiFi instead of USB/FTDI connection. So this might be more accurate answer to this improvement. Just as @terjeio said:

A "native" USB connection or network connection is usually at least an order of magnitude faster - sometimes a lot faster than that.

but have not had any feedback yet that e.g. the http daemon affects performance. If you can shed some light on what you experienced I am all ears.

This is just my assumption. I'm sorry. I didn't wanna offend anyone. I'm just guessing that if some module resides in chips memory and is ready to use it can affect performance a bit. I don't have anything to support this theory. Except maybe for a ping time which was above 50ms maybe even more and now I have below 10ms. But all in all it might just have been the fact that I switched to WiFi.

[terjeio]

This is just my assumption. I'm sorry. I didn't wanna offend anyone.

I was not offended at all - I was just curious about what happened. Sometimes obscure bugs may surface - and I am keen to track those down and fix them. E.g recently I fixed one that was carried over from legacy Grbl that must have been present for many years, and one that was quite bad to boot. So keep on reporting irregularities!

[petervanderwalt]

But all in all it might just have been the fact that I switched to WiFi.

It would be unexpected, but good to know. I would expect the wifi overhead to be slower than USB (FTDIs served us well for a long time). Just to clarify, that was Wifi using CONTROL's Telnet connection right? (Not SD card via WebUI over wifi?)

[normanruta]

It would be unexpected, but good to know. I would expect the wifi overhead to be slower than USB (FTDIs served us well for a long time). Just to clarify, that was Wifi using CONTROL's Telnet connection right? (Not SD card via WebUI over wifi?)

Just scanned network and and picked an IP address of a blackbox. Not sure if it's telnet though.

There might be another factor here. I'm Using Macbook Air M1 (8CPU/8GPU, 16GB RAM) with parallels and windows 11 on it. Black box was connected via USB-C to USB-A adapter. Haven't had any issues with a transfer speed using for example pendrive with this set up. But maybe it introduces some issue with FTDI. I have had some troubles with making FTDI work with Windows on paralles in the past but I managed to overcome this. It turned out that drivers had to be picked from a folder that is not shared between VM and the host. Anyway Windows itself runs great. No performance issues here.

I know that there is a Control available for mac but 1.0.348 couldn't access FTDI (no showing on the list) nor scan the network (no results). Even though I granted full disk access. And then I tried version 353 and 354 but Control's window does not show up at all. Only macos top menu changes to Control's but that is it. I tried uninstalling it completely with AppCleaner so all config files that might reside would be deleted but that didn't helped as well. So I keep using Control on Windows VM.

[petervanderwalt]

Thanks for confirming, we'll setup for some testing after the current high priority task - interesting observations, looking forward to playing with it (:

Yes, CONTROL's built in connection is via Telnet

[armmaker]

Our included firmware on BlackBoxes might be older than that for sure, so if there has been commits since, then @normanruta please build a new Build using http://svn.io-engineering.com:8080/?driver=ESP32&board=BlackBox%20X32 (set Y to Ganged, Set SD Card to Enabled on Plugins tab, and set WebUI, Wifi, Telnet, Websocket, HTTP on Networking Tab - to match our usual firmware options) If you grab the WebUI V3 follow https://github.com/grblHAL/Plugin_WebUI/#installation to install it if you want to check it out

This was super helpful for me and resolved the issue that I was having with my OpenBuilds Blackbox X32

[petervanderwalt]

CONTROL has been updated with newer firmware images a while back - you can now use the included images (or Web Builder for even newer firmware)