CNC style Pendant

FelixH

Oh, I see. It is either the pendant or the display... well, that's a bummer. The display it's quite useful to start jobs and many other things... Anyway, I'll keep an eye on it

JoergS5

@FelixH If you need PanelDue also, you could consider a solution similar to SMUff https://github.com/technik-gegg/SMuFF-Ifc where an ESP32 is between and allows two devices using the interface.

FelixH

@JoergS5 that's a neat project! However, I will quote Rocket Racoon on this one... "I go for the simple things"... would it be possible to just attach a switch on the UTXD0 and URXD0 pins and flip the switch to the input device you need?. It's not like I need to use them both simultaneously, I think... I guess the answer is no, but still it would be the simplest thing to do

arhi

@FelixH said in CNC style Pendant:

would it be possible to just attach a switch on the UTXD0 and URXD0

double pole double throw switch should work without a problem for this purpose selecting one or the other device

arhi

@dc42 said in CNC style Pendant:

I've written the Arduino Nano code for the pendant-to-PanelDue-port interface

question. are you sending many short G0 while receiving impulses from the encoder or you scan at a certain frequency (e.g. 2Hz or 10Hz) and then send G0 according to what encoder did between scans? I'm making this wifi pendant for a while now and having issues deciding what I want. First version I made with buttons, then replaced buttons with a stick but now stick is behaving like buttons (you have to move stick for each movement and select increment on other button) and I don't like it. now I'm attaching analog stick so I can use 2-3 different speeds according to the angle of the stick but again, don't know if I wanna send ton of 0.1-10mm gcode's in a loop, or do 2Hz scan and send only gcode's at that frequency. You for sure have more experience with this so know what might be better solution. I guess analog stick is similar to the encoder so decisions should be similar :). Now I'm thinking about adding encoder to the stick too (I'm never going to finish this, first screen, then stick, then analog stick, now encoder... neverending story).

p.s. I didn't want to go with "ready made pendant" as they were "expensive", now looking at %$#^^@$# I crammed in to the box it's more expensive than ebay

dc42

@arhi said in CNC style Pendant:

question. are you sending many short G0 while receiving impulses from the encoder or you scan at a certain frequency (e.g. 2Hz or 10Hz) and then send G0 according to what encoder did between scans?

I've written it to accumulate movement from the encoder and send it only when the UART transmit buffer is empty. I suspect this will still be too often, and I will need to send it every X milliseconds instead, or immediately if we haven't sent a command for the last X milliseconds.

FelixH

Yesterday I got my Pendant, exactly as the one pictured. I could start working on the implementation on my spare time

dc42

@FelixH said in CNC style Pendant:

Yesterday I got my Pendant, exactly as the one pictured. I could start working on the implementation on my spare time

I'm still waiting for mine, but feel free to try my code. It's at https://github.com/Duet3D/CNC-Pendant-Firmware.

arhi

@dc42

Serial.write("M112 ;" "\xF0" "\x0F" "\n");

any special reason for 0xF00F between M112 and 0x0A ? I see it comes after ; so it's a comment but ?

dc42

It's a special emergency stop code recognised by the input buffer code on the Duet, so that the emergency stop command bypasses the command buffers.

arhi

@dc42 great, good to know

arhi

@dc42

      int distance = encoder.getChange() * distanceMultiplier;
      if (axis >= 0 && distance != 0)
      {
        whenLastCommandSent = now;
        Serial.write("G91 G0 ");
        Serial.print(distance);
        Serial.write('\n');
      }

seems to me axis is missing from the G0 ?

dc42

That's because I failed to complete a recent change. Change the line:

Serial.write("G91 G0 ");

to:

Serial.write(MoveCommands[axis]);

arhi

@dc42 do you think it's better for wireless pendant to telnet to the RRF and send G-codes or to exec g-codes trough http://rrf/rr_gcode ?

gtj0

@arhi said in CNC style Pendant:

@dc42 do you think it's better for wireless pendant to telnet to the RRF and send G-codes or to exec g-codes trough http://rrf/rr_gcode ?

If you use http, you can use the pendant with either a Duet in standalone mode or via the DSF (with a slight change to the URL).

arhi

@gtj0 that's the reason I'm asking. HTTP approach looks better but dunno if there are penalties. I went forward last night and since I need a "send g-code" function in one place only it's not a big deal to have few different ones (one for telnet, one for http, one for - whatever...) as it will not be affecting the code.

I took a 2stick module from some broken game controller, that gives me 2 buttons + 4 axes with limited speed control (2k2 pots on the axes are not very precise, I can safely detect 2 speeds, maybe 3 especially as I added 4k7 in series so the swing is even lower, I might remove the 4k7 but 4x2k2 in parallel on the 3v3 rail is 6mA constant drain on the battery), attached to ESP32+BMS.

Telnet works for now but I'm still thinking if I need to add more buttons and leds.

Danal

Somewhere in all the above I ordered a pendant a few weeks back. JUST after I ordered it, Dave published his code. Which is great, not having to write it... so I haven't done much since then.

I have received the pendant now.

I'm thinking about an ESP32 (massive, massive, overkill, but they are $5 each...!) setup to do Serial or Network, including RRF2 or RRF3 printers. And just experimenting to see if it "feels" right when hooked up by various methods.

And a battery and an "off the shelf" USB charger/manager for the battery.

Going back and forth on having a small display, XYZ.

IMG_0502 (1).jpeg IMG_0503 (1).jpeg