Grbl_ESP32_MPCNC_Controller
Grbl_ESP32_MPCNC_Controller copied to clipboard
bdring
more flexible support for stepstick modules
In the next revision, could you provide support for more advanced stepper modules?
this would require that the three config pins have a way to set them individually or have them connect to spi (for the most advanced features)
If this could support the tmc2130 modules, you could potentially eliminate limit switches.
I'm thinking of a 3 pin jumper for each of the config pins, high, low (one side connected or removed) or spi (other side connected)
I have other Grbl_ESP32 boards with SPI driver support. It can use a lot of extra I/O. You need a Chip Select pin for each driver.
I have a test board that uses one CS pin for all drivers. It works, but requires modifications to the standard library. Those mods are write only at this time. It does allow you to setup all features.
@bdring can you share the artwork for this board variant please? possibly as a new branch called "trinamic" or "spi" or similar? even just the schematic would suffice, as I dont use diptrace (mainly KiCAD or Altium).
and are you still daisy-chaining the trinamic modules? (ie. all 4 of them use a single CS line?)
OK. I am out of town, so it will take a day or so.
I have a few extras assembled. I would be willing to part with one, but only to seasoned programmers, that can help move this forward.
I dont expect a handout of hardware mate, please share the design and I can spin my own board up if need be, happy to assist with firmware if needed also.
Attached is the schematic.
I am away from my office until Aug 20th on vacation. I do not have time to create a proper repo for the controller.
I can send the gerbers via email or Slack, but I do not want to publicly post them without well documented repo.
The controller uses this branch of Grbl_ESP32. It requires this fork of the TMCStepper Library for daisy chain support.
Currently you can only write to the drivers. I have some code to read, but I have not tested it at all and I am sure it does not work yet.
To save pins, the SPI data lines are shared with the SD card. The SD has its own CS and the drivers share a CS. You must install 4 drivers or jumper the data through any missing drivers.
What are the currently "working" methods of receiving grbl strings? wifi-serial, usb cable, read g-code file from sd card, etc? Cant really tell from what I have read (without reading through the source, which I will be doing) where you are roughly up to?
We treat the communications methods as separate channels. If Bluetooth asks for status, only Bluetooth gets the status.
The serial port is treated as the debugging port because it is always there and survives a reboot. You do not loose the connection during reboot. A lot of startup info and debugging is sent there.
See grbl_send(...) and grbl_sendf(...) for more info.
I was hoping for something with 5 axis support (looking at the lowrider 2)
I have designed my own PCB to use your TMCStepper branch of firmware. It can be found here if you are interested, I have referenced you accordingly. https://github.com/dvisser/NodeMCU-ESP-32S-3-Axis-CNC-Controller
That looks good.
While the output of the spindle is PWM, it is on one of the ESP32s 8-bit DAC pins. With a small firmware change, you might be able to simplify your spindle circuit a little.
it is still a work in progress, but thank you. I am very much used to Altium Designer (over 10years experience) and still learning KiCAD.
I wasnt aware we had a DAC peripheral, that does sound interesting and is worth looking into, it would remove the need for the PWM to analog DAC IC I was planning to use.
please could you invite me to your slack workspace (never used slack, but keen to see what it is like)
The option to output DAC or PWM might make your board more flexible to use other speed controllers.
invite sent
indeed, so might be worth keeping the current hardware configuration I guess.
Just joined slack also. Thank you.
you mentioned a few posts up that I should consider posting a bounty to get a 5+ axis controller that would support the smart stepper modules, how big a bounty are you talking about?
I understand the argument that homing isn't that important for a CNC, but for something like the MPCNC or the lowrider2, it's especially easy to get the two sides out of sync with each other and have the machine be racked. So having the ability to run against a stop as a squaring routine (potentially slightly different than a homing routine) is something I find attractive.
I have this problem on my dual Y 3d printer where the two sides can get out of sync when I transport it, and the lowrider seems especially sensitive to this problem.
so something that can drive 2130 or 2209 modules so that it can just run against limits rather than having to wire endstops is attractive. (long endstop wires close to electrically noisy routers isn't a great match)
David Lang
If using 2130's or 2209's you could use stallguard whilst homing/crashing to square up the axis. Pretty simple. I can assist with code if needed, but this is bdring's party :-)
On Mon, 2 Sep 2019, Dan Visser wrote:
If using 2130's or 2209's you could use stallguard whilst homing/crashing to square up the axis. Pretty simple. I can assist with code if needed, but this is bdring's party :-)
That's exactly what I'm hoping for, but before you can write the code for it, you have to have a way to communicate ith the 2130/2209
David Lang
@davidelang bdring's firmware (Tmcstepper branch I believe) already talks to daisy chained 2130's. Only one way at present. I have code that I have forked that does both ways. I bet he isn't far off either. I could always put a pull request in once my code is polished anyway. But you could use bdring's FW and simply set the diag1 pin to toggle on trigger of stallguard and connect that to your relevant axis limit SW input pin.
My branch only writes in daisy chain mode. I worked a little on daisy chain reading, but never finished it.
Setting up stallgaurd is tricky, especially if you have long stepper wires. You are trying to measure power losses in the motor coils. If you have wiring losses, that needs to be "tuned" out. Also, stallgaurd does not work well (false or missed stalls) at very low or very high speeds. You typically need to tell stallgaurd the speed window where it should trigger the stallgaurd signal.
You need to be able view a fast stream of stallgaurd data to do that tuning. Reading is needed for that. Also Grbl is not a very good platform for tuning. You want a program that runs the motor at a constant speed for long periods of time and has the ability to adjust the speed and tuning values on the fly.
I ended up making a separate program for tuning and just loading the tuning values into Grbl.