I have built a custom machine that will run in a similar manner to a tangential knife cutter (similar to a drag knife except the knife rotation is controlled with a 4th axis). It has 1 motor for X, 2 motors for Y (one must run in reverse), and 1 motor for rotation around Z (C axis). The Z axis will be actuated with pneumatic piston, fine positional control is not needed, only in and out. How do I set this up in the black box control software? There are 4 stepper drivers and 4 motors on the machine so it should be possible, I'm just not sure where to start.
CONTROL > Wizards and Tools > Firmware flashing tool > i'd say try the 4th axis firmware first, most tangential CAMs would expect the rotary tool to be an A-axis. Otherwise, http://svn.io-engineering.com:8080/?driver=ESP32&board=BlackBox X32 for custom config Z as a solenoid is a bit nonstandard, having a motorised Z might be helpful for pressure setting / cut depth. Most CAMs would output Z command instead of M codes for solenoids anyway. Both Ys just in parallel on Y1, frees up Y2 as the A axis driver
I'm looking at the documentation for wiring now. Just to be clear, both Y motors will connect to Y1 on the box with the connections reversed at one of the motors?
Small problem. Is there a way to configure this to use the Z stepper driver for the A axis so that I can keep using both Y drivers instead of just one? The gantry on this machine has counterweights to cancel out the weight but it has a lot of inertia (the machine is vertical). The Y stepper driver is losing steps and overheating if I turn up the voltage.
I appreciate your help, but I'm a total noob. Can you walk me through how to do this? Or atleast point me in the right direction?
use OpenBuildSCONTROL to install the standard XYZ firmware. that gives you Y1 and Y2 both driving Y motors, one driver per motor. then connect Z to your rotary knife I would connect the up/down solenoid to the coolant output, M8 for down, M9 for up. now you have a custom machine that no standard gcode generator is going to support. if you cannot do the programming yourself, you will need to find someone on something like Upwork to do it for you. This can be done in at least 2 ways a) generate standard Gcode as though it is a router, but turn all arcs off, everything must be line segments. now your programmer creates a program to input that gcode, translate Z movements into M8/M9 codes and figure out the angle of each line segment and drive Z to that angle, outputting custom gcode to do this. b) if you are using CAM that has postprocessing, such as Fusion360, then modify the post to output your custom Gcode directly. (fusion posts are javescript, that will help you find a progammer) these links may help you Tangential knife support - Autodesk Community Solved: How to CAM for oscillating knife - Autodesk Community
Checkout GitHub - grblHAL/ESP32: grblHAL driver for ESP32 Our default pinmap ESP32/main/BlackBoxX32_map.h at master · grblHAL/ESP32 and our custom homing mapping driver ESP32/main/BlackBoxX32.c at master · grblHAL/ESP32 Both needs modification and then custom compile Too high is perhaps the root mistake. Dial it in Correctly (not too high) so you can use the stock configs as intended. Using that also ensures compatibility with existing CAM workflows. If needed, swopping in our low inductance motors, or dialing back the expectations on acceleration etc. Skipping steps rather indicate a lack of tuning of acceleration and max rates. The drivers on BlackBox shuts down when overheating (reset through a power off / power on) it doesnt cut out intermittently
I was able to write some code to modify the gcode like you suggested, and it worked. The problem is that it is a rotary axis that openbuilds control thinks is a linear axis. There's 28mm of "linear" travel to rotate 360 degrees, so the program finds the angle of each line segment and the corresponding z travel for that angle and edits the gcode. When the machine is tracing a circle, the z motor moves to the correct angle, but when it passes the 0 degree point it spins all the way back to the beginning instead of continuously rotating. It reaches 28mm at 0 degrees and then spins back to 0mm to continue rotating from there. I cant think of a good workaround for this. Ideally I could change the Z axis to be rotary or remap the A axis to Z in the firmware but I'm having trouble doing that. I set up ESP IDF in visual studio code but I don't know where to go from here. Is there a way to view the source code for the default 4 axis firmware so that I can use it as an example? If I were to change it, how do I compile it into a .bin file to flash onto the board?
yes, this is a common problem with rotary axes and is solved in postprocessors by detecting when a rewind is needed and then doing a 'retract/reqind/restart' sequence to get past the rotation limits. another way may be to extend the 'length' of the axis to allow , say, 10 turns. your program will need to keep track of how many turns have been done and still cater for rewinds but there will be much fewer , or maybe none if you allow enough length. so if you set the length to 280, then 0 to 28 is one turn, 28 to 56 is another turn and so on. if you setZero at 140 you then have 5 positive turns and 5 negative turns. of course I am using 10 as an example, the controller can handle about 100 meter long axes..... depends on the microstepping rate. I don't think there is a way to replace Z with A, maybe @terjeio can help you with that
The default 4 axis driver changes the y2 driver to the A axis. I feel like it shouldn't be difficult to change the z axis to the A axis instead. I just don't know how to do it. Do you know any programmers I could hire that could do this? Should he very simple for some one who has made changes to the firmware before.
Once I make changes to those files in ESP IDF, how do I compile it? I'm not a programmer and im worried about frying the board. I am willing to pay for someone to do this for me.
No, you create your own pinmap (or modify existing one) - ESP IDF is a Framework: GitHub - espressif/esp-idf: Espressif IoT Development Framework. Official development framework for Espressif SoCs. The grblHAL Readme has instructions: Going the route of nonstandard - sadly comes with complications. Your choice though... Either battle through them and learn some things along the way, or follow the advice in the earlier posts - build the machine "more standard" with Parallel wired Dual Y's and A where its intended (on Y2). Saves all the effort. I did mention that in 2nd half of Post #9 too: Not only can you use standard, available firmware, but also less messing with CAM workflows
Remapping of A to the Z stepper driver can be done, but will require a new board map and a modified driver.c. The next release of grblHAL might not require modifications to driver.c, only a new board map, so is worth waiting for? My plan is to publish this release mid december provided testing goes well.
Did you ever end up doing this? I found a slightly janky work around but this sounds like a better solution.
