aux input/output udp packets via bridge

[jschoch]

I was thinking that if you used an esp32 SPI -> ethernet bridge it may be nice to use the esp32's ADC ( even though it is crap) and or other GPIO's or other peripherals (RMT/I2C/SPI/I2S, display/UART/WifI & Bluetooth). Since the esp will be sending the UDP packets maybe it could send a 2nd type of update packet with data it collects? This could be useful for slower IO. Are you open to this idea?

I've been resisting making another board but if I could use the ADC and or GPIO for LCNC GUI controls buttons/switches/pots it may be worthwhile.

[multigcs]

hmm, possible, but...

the WT32-ETH01 i use, has very few free pins, I would like to use these to be able to flash the FPGA later on

if you need an ADC, you can use the cheap ads1115 boards and connect it to 2pins of the fpga.

if you need more Digital IO's, you can use shiftreg-boards or the cheap CPLD EPM240 board. the advantage of this is that you can assign almost all functions to these external pins (except INOUT like I2C/SDA or highspeed stuff)

[jschoch]

based on NCM USP being built into s2,s3 and the simplicity of just connecting it via USP I'm thinking that maybe I can do a separate project to do remote MPG/HID type stuff and just send it to a different UDP port with it's own HAL component.

That begs the question: How do you add other HAL components into riocore? The ability to add a template HAL file and have that processed via some python and appended would be nice. If you are open to that I can try to add that to the list of PR's I want to make.

[multigcs]

i have already add joystick, hy_vfd(via USB) and Camera config support to the hal generator, i will figure out how to abstract this parts, so we can add more with a kind of plugin system.

[jschoch]

i need wireless MPG, the mass wires are killing me already and I don't want any more ;)

[multigcs]

I would need one too but can't make up my mind

the WHB04B-6 works with linuxcnc and is wireless and doesn't cost too much.

on the other hand, it would be an advantage for the project if i could get a normal one with cables to support it properly.

but yes, too many cables :)

another possibility would be via modbus, but that is often slow

[jschoch]

Cool! there is a branch in my fork USB networking test (tinyusb) that can receive packets from espnow and send them on via UDP. The MPGData struct is the packet format the espnow sender needs to send, the client isn't in there but you can take a peek to see how it works.

[multigcs]

ESPnow works also from linux directly and very fast: https://hackaday.io/project/161896-linux-espnow

not tested on raspberry, but works on my Desktop PC with USB-Wifi-Stick

[multigcs]

about MPG, i try to build a hardware for it: https://www.cnc-aus-holz.at/index.php?thread/3366-wireless-mpg-f%C3%BCr-linuxcnc/&postID=39623#post39623

[jschoch]

site is down but I could read it via google cache -> google translate. Pictures didn't come though.

My prototype is using msgpack and using the python user land comp. I'll try to get something up on github.

It basically does the msgpack encoding on the esp32, sends that out over esp_now, the usb network bridge just forwards it to a server/IP and the comp uses python matching to grab the data.

Apparently there there is a lack of state coordination between linuxcnc and the "gui" and so you have to take care to deal with axis selection since that state may get out of sync. There is a thing called gstat that you may want to look at

https://linuxcnc.org/docs/master/html/gui/gstat.html

also, apparently mpg jogging is "different" than other types of jogging but I haven't found out the details yet.

[multigcs]

https://github.com/multigcs/linuxcnc-mpg https://forum.linuxcnc.org/18-computer/52044-diy-mpg-based-on-esp32s2

[jschoch]

https://github.com/jschoch/now_pendant

I have button envy, but looks like we both chose 4 encoders....

Maybe we should combine efforts, but maybe the hardware differences are too much?

[multigcs]

also the software is different (arduino vs pure espressif)

[jschoch]

the bridge is idf, the pendant is platformio/Arduino I think the bridge should be optional and maybe can easily just be a binary that never really needs updating, just some way to set the IP addrs.

I'm not very happy with my scale selection via crappy ec12 encoders, the detents are annoying.

[multigcs]

i don't really know how to combine the two, as the projects are as good as finished (usable)

I still have to think about something for the 'scale selection', I didn't want to use an encoder or rotary switch for either the 'axis selection' or the 'scale selection'.

i am thinking about how to make a double assignment of the buttons (long press)

espnow is working: https://www.youtube.com/watch?v=mJ1qc-PS2gQ

[jschoch]

I was thinking it may be possible to 3d print a detent, let's say 30-40 degrees of an encoder rotation, and then map some range on the encoder to match up with the detent. Then there is the problem of state but it may not be completely impractical to save it in nvram.

here's my current solution, which sucks. i don't think it should wrap...

def scale_ticker(ticker,dir):
    if(dir):
        if(ticker > 4):
            ticker = ticker + 1
        else:   
            ticker = 0
    else:
        if(ticker < 0):
            ticker = ticker - 1
        else:   
            ticker = 4
    return ticker

...

prev_count = encoder_list[1]
        count = encoder_list[2]
        diff = sel_prev - count
        if(diff > 8 and diff > 0):
            ticker = scale_ticker(ticker,1)
            c['jog-scale'] = encoder_map[ticker]
            sel_prev = count
        elif(diff < -8 and diff < 0):
            ticker = scale_ticker(ticker,0)
            c['jog-scale'] = encoder_map[ticker]
            sel_prev = count 

I have to turn on velocity mode, your video looks like that motor is very smooth.