Project Logs

Collapse

• Makerbase Servo42C for FOC based wire tension control

  gedm-dev • 2 days ago • 0 comments

  Building the new EVOIII router is still a long road to go and one of the major changes is the way the wire is controlled. It uses the wire feeder from the Pico designed by Alex Treseder.

  The wire feeder has to steppers. One stepper drives the pulling side while the other one will monitor and keep the desired wire tension using the Servo42C driver in FOC mode.

  The full wire unit will be controlled by this tiny ESP32 from Seeed. Next to it is a normal ESP32-Wroom board to get the size.

  I want to program the driver using the G-EDM UI but well, there is no library available. The documentation is all there is and it looks pretty complicated. They do provide a closed source interface for windows but that doesn't help much.

  Writing a library for this driver to be able to fully control it is everything but not noob friendly. And I mean it.

  First it doesn't use normal integer value that are send around via UART. It uses hexadecimal values. And they are limited to 8bit. The format for sending data to the driver is like this:

  slave_address command data1 [data2 data3 ...] checksum_modulo_256_8bit

  slave_address command data1 [data2 data3 ...] checksum_modulo_256_8bit

  If the data value exceeds the 8bit it needs to be split across multiple cells as big-endian byte array or something.
  
  

  I don't have the driver yet and all this is just extracted from the documentation that shows this for the max torque setting (manual example sets the value to 600 = 0x258 = 02 58):

  The command for setting the max torque to 1200 would look like this:

  E0 A5 04 B0 39

  Let's break that down.

  E0 is the slave_address used to identify the driver.

  A5 is the command to set the max torque

  04 B0 is the tricky part. It is the formatting of 0x4B0 (Hex representation of 1200). A number larger 255 exceeds the uint8_t (0-255) limitation and therefore it is converted into two cells or more if the number is really large.
  

  The last cell always contains the checksum of the previous cells also limited to 8bit. I think it is called modulo 256. Collisions will happen but it doesn't look like a real problem. Good enough for what it is.

  How to convert the 0x4B0 into 04 B0 ?
  

  It would be no problem to convert the hexadecimal value into a string or char array and then split it but the functions should be as fast as possible and therefore it is done with bitshifting and bitmasking. Working with strings and string streams etc. is always bloated and slower. Char arrays are somehow uint8_t and would work. But let's not get into that. I want to shift some bits.

  The start of the code looks like this:

  #define MAX_BYTES 4 // maximum input is 32-bit
  
  enum COMMANDS_42C {
      CMD_SET_MAX_TORQUE = 0
  };
  
  std::map<COMMANDS_42C, int> servo_commands = {
      { CMD_SET_MAX_TORQUE, 0xa5 }
  };
  
  static const int MAX_POS_TORQUE = 1200;
  
  
  bool SERVO42C::set_max_torque( int torque ){
      if( torque > MAX_POS_TORQUE ){ // max pos torque is static const int 1200
          torque = MAX_POS_TORQUE;
      } else if( torque < 0 ){
          torque = 0;
      }
      return send( servo_commands[CMD_SET_MAX_TORQUE], torque );
  }
  
  
  // Function to convert an integer into an array of bytes (formatted as hex)
  void SERVO42C::int_to_hex_array(uint32_t value, uint8_t *array, int *length) {
      // Determine how many bytes are needed for the value
      int needed_bytes = 0;
      for (int i = 0; i < MAX_BYTES; i++) {
          if (value >> (i * 8))
              needed_bytes = i + 1;
      }
      *length = needed_bytes;
      for (int i = 0; i < needed_bytes; i++) { // Fill the array with bytes, starting from the most significant byte
          array[needed_bytes - 1 - i] = (value >> (i * 8)) & 0xFF;
      }
      if( length <= 0 ){
          *length = 1; // at least one cell even if value is zero
      }
  }
  
  uint8_t SERVO42C::create_checksum( uint8_t *hex_blocks, int block_num ){
      int sum = 0;
      for( int i = 0; i <= block_num; ++i ) {
          sum += hex_blocks[i];
      }
      return sum & 0xFF; // Mask to 8 bits // modulo 256
  }
  
  
  bool SERVO42C::send( int command, int value ){
  
      uint8_t hex_array[MAX_BYTES]...

  Read more »

• EVOIII Router - more build pics

  gedm-dev • 05/02/2025 at 14:24 • 0 comments

  So far the Pico wire feeder works well. Will add a few changes to it but all in all it is very good. Enough friction to break a 0.2mm wire and pulling the wire out will also move the belt and stepper.
  
  
  

• EVOIII Router (work in progress) build pics

  gedm-dev • 05/01/2025 at 19:54 • 0 comments

  Random images showing the build progress for the EVOIII prototype.

• G-EDM EVOIII Motionboard is tested and works

  gedm-dev • 04/25/2025 at 17:42 • 0 comments

  Did a quick test of all the features on the new motionboard and it seems to work.

  1. Isolated RX/TX to program the DPM/DPH ✔
  2. Fan ✔
  3. ON/OFF switch ✔
  4. LIMIT switch ✔
  5. Display ✔
  6. SD card on display or via little adapter card ✔
  7. Connection to the pulseboard ✔

  Looks pretty nice. Display in this case is 2.8" ILI9341 SPI Touch XPT chip
  
  

• Thanks to J.B. for delivering a smile

  gedm-dev • 04/24/2025 at 11:18 • 0 comments

  Just received a little package from the US containing PCBs in bright colors that are made thicker then the ones I order.
  

  The package included some cards and stickers and they made me happy. Thanks to J.B. for that. 

  New Southpark season coming soon. Looking forward to it. They have a lot of crazy stuff to work with.

  I deleted the old mail address and don't have your mail anymore. If you see this please reach out to: gedm-support@proton.me
  

  If you need help with your EXO project let me know. Wanted to make one for a friend too but decided that without team it would blast the budget and time.
  
  
  PS: The thicker material on the pulseboard is indeed a good choice. On the motionboard it doesn't make much difference but for the pulseboard using a 2mm thick PCB instead of 1.6mm makes a big difference in flex. 2mm recommended from now on.

• Testing the EVOIII Motionboard

  gedm-dev • 04/23/2025 at 19:44 • 0 comments

  The new EVOIII Router asked for a new motionboard that provides a better layout of the terminals. The core circuit is the same as the one used on the EVOII Motionboard but the connectors are placed more thoughtful.

  One new feature is the option to connect an SD card module directly to the PCB. This should allow using longer wires for the display without risking data loss on the sd channel.

  The common micro sd board seems to be made for arduinos 5v and does not work without hacking it. It has an AMS1117 voltage regulator on board that needs more then 3.3v input.

  I just removed it and bridged two pads. This way it works. Maybe there are better solutions available.

  This is just a feature for testing. Using the displays integrated SD card reader still works too.

  I'm waiting for the new WAGO terminals and then have to test the isolated RX/TX channels once it is wired up.

• New G-EDM C-Arc design to guide the wire

  gedm-dev • 03/28/2025 at 02:30 • 0 comments

• Working on the new G-EDM router with integrated electronics

  gedm-dev • 03/14/2025 at 21:46 • 0 comments

  The current router works very nice but there is so much room left to improve things. Especially the external control box adds to the footprint. The next one will have everything integrated.
   

  Integrated electronics

  Less weight

  Cheaper

  Easier to build

• Winner of the 7th PCBway design contest, new Panel and new Firmware

  gedm-dev • 03/10/2025 at 10:24 • 0 comments

  Great day for DIY EDM. The G-EDM won the first prize at the 7th PCBway design contest.

  https://www.pcbway.com/blog/News/Meet_the_Winners_of_the_7th_Project_Design_Contest_f25c1e31.html

  And there is also a new controlpanel on Github that can be mounted from the front and gives easier access if needed:

  https://github.com/G-EDM/EVOIII-ControlPanel

  And another major update is a new firmware release that has many bugs fixed and comes with a full makeover of the user interface:

  https://github.com/G-EDM/PhantomEDM
  

  
  

• G-EDM EVOIII board - pulse and sensing merged on a single PCB #wireEDM

  gedm-dev • 12/02/2024 at 20:54 • 2 comments

  G-EDM EVOIII
  
  

  The new EVOIII board provides a single PCB containing the pulse stage and the sensing stage. It replaces the EVOII pulseboard and the EVOII sensorboard.

  
  

  The EVOII Cube is a cool looking piece of Art but it is hard to manufacture. To reduce build costs and make it easier to produce the EVOIII PCB was designed. Specs and performance of both versions is the same. There is one difference: The EVOIII uses a single gate driver IC while the EVOII cube has a discrete gate driver circuit. At higher frequencies they don't switch identically and the cube needs a slightly higher duty cycle.

  The board provides two isolated analog feedbacks and also isolates the PWM to drive the mosfet gates.

View all 81 project logs