Open yaapu opened 3 months ago
Hmm, I think the new task executor might be a cleaner fix.
Change this line to: task_add_immediate(keypad_process_keypress, NULL);
and add code to keypad_process_keypress()
to handle the selected keys in estop/alarm states.
Changing this line in the same manner will then make the UART and I2C keypad streams behave in the same way.
I tried your suggestions but I've only had partial success, couple issues 1) I had to change this line to also check that we were jogging otherwise 0x18 would never pass 2) your solution seems to work as long as a sender is connected to the main stream, as soon as I disconnect the main stream status reports stop being responded to (actually I get 4 responses and then silence) just like there was a queue in place that is serviced as long as the main stream is active, I should have mentioned that my point was to allow my mpg/keypad device to work even without a sender by polling status without entering MPG mode
does this make sense to you?
I'm testing on a makerbase DLC 32 so ESP32 driver, the board is not powered by USB. I do have a PicoCNC which is my "production" board so I rather not play with it
I'm testing on a makerbase DLC 32 so ESP32 drive
Real-time requests are not passed through from the keypad plugin, the version above should do so. But perhaps it should not, in normal operation two clients should not requests status reports simultaneously, either enable auto-reporting or MPG mode? With MPG mode enabled the keypad client should take full control if the main stream is silent and only then request regular status reports.
This is something I already tried, I commented out the line you changed, but as I told you I can see the status request command coming in but I get a response for the first 4 polls and then silence. to debug I use hal.stream.write_all and when the main stream is disconnected I don't get any debug on the MPG uart.
I understand that status report should only be requested while in exclusive access, but right now my code checks for status reports and if none are received starts polling (without entering MPG) and as soon as reports are detected (with a period less than 250ms) it stops requesting, some sort of automatic fallback.
Do status polling requests pose some risks if for any reason they are received from 2 streams?
It might be that one of the stream output buffers fills up and then blocks? This function will be called repeatedly if so.
Do status polling requests pose some risks if for any reason they are received from 2 streams?
Some senders may not like to get unsolicited reports, so I consider it risky.
ok, then I'll have to try a new approach: if I detect no status reports for a least 250ms I automatically enter MPG mode MPG mode OFF will have to be an explicit operator choice
I'll let you know if this along the changes you suggest will allow for reset and unlock in estop and alarm modes
I have a ESP32-S3 dev board at hand and just verified that keypad status requests get sent to the MPG stream even when the main stream, which is a native USB stream, is not connected to a client. I have only one USB C cable available so cannot check that the USB stream is getting data when connected, but I believe it is. So it is likely that the main stream somehow is blocking output if a client is not connected - which is kind of odd since I am pretty sure ESP32 dev boards do not do so. Perhaps the DLC 32 is designed to block output to the main stream if there is no client connected?
I have a ESP32-S3 dev board at hand and just verified that keypad status requests get sent to the MPG stream even when the main stream, which is a native USB stream, is not connected to a client. I have only one USB C cable available so cannot check that the USB stream is getting data when connected, but I believe it is. So it is likely that the main stream somehow is blocking output if a client is not connected - which is kind of odd since I am pretty sure ESP32 dev boards do not do so. Perhaps the DLC 32 is designed to block output to the main stream if there is no client connected?
MPG or keypad stream? Remember that in my use case scenario MPG is not enabled, perhaps that's the issue?
MPG or keypad stream? Remember that in my use case scenario MPG is not enabled, perhaps that's the issue?
Ok, the keypad plugin alone is input only. If you want output to the stream used by the keypad you have to enable MPG output (mode 1) as well. More here.
MPG or keypad stream? Remember that in my use case scenario MPG is not enabled, perhaps that's the issue?
Ok, the keypad plugin alone is input only. If you want output to the stream used by the keypad you have to enable MPG output (mode 1) as well. More here.
sorry I should have said MPG is enabled but MPG mode is off i.e. MPG:0, and when MPG:0 I'd like to be able to request status reports and allow for unlock and reset
but I understand that's the very reason you provide MPG mode :-) I was hoping to replicate what Log2K does but it's using I2C so another story actually
add X (and H) to the tests in line175+ to keypad.c I linked above:
if(state == STATE_ESTOP && !(keycode == CMD_STATUS_REPORT ||
keycode == CMD_STATUS_REPORT_LEGACY ||
keycode =='X' ||
keycode == 'H' ||
keycode == CMD_RESET ||
keycode == CMD_MPG_MODE_TOGGLE))
return;
ok?
add X (and H) to the tests in line175+ to keypad.c I linked above:
if(state == STATE_ESTOP && !(keycode == CMD_STATUS_REPORT || keycode == CMD_STATUS_REPORT_LEGACY || keycode =='X' || keycode == 'H' || keycode == CMD_RESET || keycode == CMD_MPG_MODE_TOGGLE)) return;
ok?
unfortunately I already tried relaxing these conditions by commenting it and no joy, but I'll try using proper MPG mode and should work
My memory is failing me, too many details to keep track of... This should be ok: keypad.zip
My memory is failing me, too many details to keep track of... This should be ok: keypad.zip
this does not work on DLC32 but does work on STM32Fxx, so I guess that on the DLC32 somethink is blocking the tx buffer, so thanks a lot :-)
Hi, I'd like to be able to reset, unlock and get realtime status reports while in alarm or estop, I kind of hacked the code together getting an inspiration from the Log2k plugin code, it "seems" to work all right but I might be missing something. BTW I had to remap macro codes for making all this work to 0xF[1-8]
this is my branch https://github.com/yaapu/Plugin_keypad/blob/yaapu/keypad/keypad.c