Pendant interfacing

Hello
I wanted to add a pendant to my cnc.
I basicaly looked at xhc series but then decided that I would rather build something cool and flexible on my own . Of course, I will waste a lot of time, rather than taking some of the shelf.
I 'm using an NanoESP32-S2 and  3.5 Nextion display.
Currently for the USB communication, I emulate a xhc so I use xhc-hb04 standard HAL module on linuxcnc side.
Beside the over complicated USB protocol, I found some "limitations" : I can display 6 axis (in G5x coords) or 3 axis in G5x + Machine Coords.
So XYZA in G5x + Machine Coords is not possible.

Do you known if there is some alternative to the xhc-hb04 HAL module ?

 

Anyway, I will try to have something working with this, regardless the A axis. Futur will tell if À axis worth the time modifying the hal module.

You could look at the Pokeys USB board as it has a linuxcnc driver. I've tested and it works (slowly) they say 15 Hz for MPG's

On usb paquet I received from xhc-hb04, it seems that randomly feedrate_ovr and sspeed_ovr are corrupted :
whb04_out_data
magic:0xfdfe
day:12
pos[0]:0,0
pos[1]:0,0
pos[2]:50,0
pos[3]:0,0
pos[4]:0,0
pos[5]:0,0
feedrate_ovr:100
sspeed_ovr:100
feedrate:0
sspeed:0
step_mul:1
state:0

setSpeedOvr:0 old:100
whb04_out_data
magic:0xfdfe
day:12
pos[0]:0,0
pos[1]:0,0
pos[2]:50,0
pos[3]:0,0
pos[4]:0,0
pos[5]:0,0
feedrate_ovr:356
sspeed_ovr:0
feedrate:0
sspeed:0
step_mul:1
state:0

whb04_out_data
magic:0xfdfe
day:12
pos[0]:0,0
pos[1]:0,0
pos[2]:50,0
pos[3]:0,0
pos[4]:0,0
pos[5]:0,0
feedrate_ovr:100
sspeed_ovr:100
feedrate:0
sspeed:0
step_mul:1
state:0

The error is always the same values (356, 0)
I checked my firmware but I can't find anything wrong on my side.
export LIBUSB_DEBUG=4 didn't help me.

On your genuine pendant do you notice some kind of glitches ?

Wireshark did. And packets emited by xhc-hb04 are not corrupted.
So the bug is on the Esp side : in my code or in the USB framework

Something weird : it seems to occur only on packet #4 and #5

It also occurs on the last bloc.
I'm afraid it's from the USB framework:
After processing a bloc of 7 bytes, I tried to fill it with the index of the processed bloc. On the next USB callback for new block, I still have the data I wrote on the previous step. So it's clear the content provided by the callback has not been updated.


Recv: fe fd 0c 0a 00 00 00 80 0a 00 00 00 14 00 07 07 07 07 07 07 07 00 64 00 00 00 00 00 15 15 15 15 15 15 15 01 00
Recv: fe fd 0c 0a 00 00 00 14 00 00 00 14 00 00 80 0a 00 00 00 14 00 00 00 14 00 00 80 64 00 64 00 00 00 00 00 01 00
Recv: fe fd 0c 0a 00 00 00 14 00 00 00 14 00 00 80 0a 00 00 00 14 00 00 00 14 00 00 80 64 01 00 00 00 00 00 00 1c 1c



 

Workaround :
After processing a bloc of 7 bytes, filling it  0xFF.
On the next callback if new block is full of 0xFF, dropping all

19:48:28.731 > Blank found on offset 0x15, droping
19:48:42.671 > Blank found on offset 0x2A, droping
19:49:10.199 > Blank found on offset 0x2A, droping
19:49:17.326 > Blank found on offset 0x23, droping
19:49:20.882 > Blank found on offset 0x1C, droping
19:49:21.689 > Blank found on offset 0x23, droping
19:50:32.587 > Blank found on offset 0x2A, droping
19:51:00.062 > Blank found on offset 0x15, droping
19:51:06.886 > Blank found on offset 0x23, droping
19:52:05.378 > Blank found on offset 0x1C, droping
19:52:12.478 > Blank found on offset 0x2A, droping
19:53:13.445 > Blank found on offset 0x1C, droping
19:53:25.142 > Blank found on offset 0x1C, droping
19:54:03.582 > Blank found on offset 0x2A, droping
19:54:09.337 > Blank found on offset 0x15, droping
19:54:39.046 > Blank found on offset 0x15, droping

Info: XHC-HB04 sends a full message every ~7ms
 

looping wrote:

Anyway, I will try to have something working with this, regardless the A axis. Futur will tell if À axis worth the time modifying the hal module.
 

I just discover that this is not needed : when the A axis is selected, it's wc and mc are feeded to the pendant using X axis values

It is alive : 
The PCB was designed for Arduino Pro Micro, so since I'm now using a Esp32S2 I have to use a bread board. I aslo added some level shifter to adapt 5V hall encoders to Esp32 3.3V I/O.

The PCB and the case will be redesign