search

grblHAL / Plugin_keypad

grblHAL keypad plugin
Other
7 stars 6 forks source link

Problem with plugins KEYPAD and DISPLAY #8

Closed zab-ig closed 10 months ago

zab-ig commented 1 year ago

Hello. ; grblHAL ; 1.1f.20230926 ; [OPT:VNMSL,35,1024,3,0] ; [NEWOPT:ENUMS,RT+,ES,REBOOT,SED,RTC,ETH,ODO] ; [FIRMWARE:grblHAL] ; [NVS STORAGE:*FRAM 8K] ; [FREE MEMORY:492K] ; [DRIVER:iMXRT1062] ; [DRIVER VERSION:230926] ; [DRIVER OPTIONS:USB.2] ; [BOARD:GRBLHAL2000 - PRINTNC] ; [AUX IO:4,3,0,0] ; [IP:192.168.0.201] ; [NETCON:Telnet] ; [PLUGIN:MODBUS v0.15] ; [PLUGIN:MODVFD v0.03] ; [PLUGIN:KEYPAD v1.34] ; [SPINDLE:PWM] ; [PLUGIN:I2C Display v0.06] ; [PLUGIN:ODOMETERS v0.04]

There were problems activating the keypad and display plugins. I use a keypad https://github.com/Expatria-Technologies/RT_Jog_Controller. If you first connect power to the keypad and then apply power to the GRBL controller, then there are no problems with the operation of the keypad and the GRBL controller - everything works fine. The screenshots show information from the i2c bus at the moment of switching on. You can see how the GRBL controller accesses the keypad and then the eeprom.

049+ACK 049+ACK+EEPROM

But if you connect the power to the keypad from the GRBL controller, i.e. power is supplied simultaneously. Or the keypad is not connected to the GRBL controller at all, then the GRBL controller does not work properly. The screenshots show that the GRBL controller is trying to communicate with the keypad, but does not receive a response from it, after which the GRBL controller does not try to contact the EEPROM. There is no further communication on the i2c bus. If you send the $$ command, a list of parameters is displayed with default values, not the values ​​saved in eeprom. 049+NAK 049+NAK-EEPROM

terjeio commented 1 year ago

Two issues at play it seems, first is that the i2c_probe() function leaves the bus stuck. The second is that there should be a delay in the display_init code before the probe is executed. I'll add 10 ms - perhaps that is enough for the display processor to start up so that the I2C address is active.

zab-ig commented 1 year ago

Thanks for the quick response. 10 ms was not enough. I tried 100, 150, 200 ms - it didn't work. As a result, I set the delay to 500 ms, with this delay the keypad and grbl controller work stably. And another question: if you connect the keypad after turning on the Grbl controller, the keypad does not work and the Grbl controller does not respond to it. Can this be fixed somehow?

terjeio commented 1 year ago

Thanks for the quick response.

You were lucky as I was just about to commit a batch of other changes...

As a result, I set the delay to 500 ms, with this delay the keypad and grbl controller work stably.

That is a long time, does the keypad code really start up that slow?

if you connect the keypad after turning on the Grbl controller, the keypad does not work and the Grbl controller does not respond to it. Can this be fixed somehow?

If the MCU I2C port tolerates hot inserts then either a $ command to initialize the plugin or an "inserted" signal must be added. Polling for it is, IMO, not a good idea.

terjeio commented 1 year ago

I'll increase the delay to 510ms in the next commit since there is 500ms of delay in the startup sequence before I2C is enabled.