I’m building a machine that needs more axis than one SmoothieBoard can supply.
Think XYZ motion with an additional rotary axis tilting the tool (not a spindle, it’s about precise tilting between 0 and 90 degrees) and automatic tool measurement and change facilities.
In operation, the machine will largely execute ‘standard’ XYZ movements. In between, it will need to go to a special position, open up the tool gripper, move the tool magazine, close the gripper, tilt the tool, then run standard XYZ stuff again.
Overall, I am currently planning with 3 steppers for XYZ, one for tilting, one for the gripper, and two involved in tool magazine handling - 7 steppers in total, all with end stops. Only 3 of those need to be quick, jerk controlled and move in sync - the others can be slower, they don’t need to move in parallel, and they won’t move while XYZ movements happen.
I’m currently evaluating which controller would be best and am having a hard time finding something with enough electrical extensibility and enough software flexibility to allow for simple movement control as well as special stuff happening in between.
I would value your opinions on the following idea: Use several SmoothieBoards. Have one control XYZ, use others for the other stepper axis. Control them from host software running on a PC via Ethernet, sending gCodes to each one in turn as processing requires.
If you are using external drives, you may benefit from a project I am working on, in fact almost finished with. My typical machines have two Z axis, however smoothie only supports one Z axis with limit switches. The other two axis can be used to move motors like rotary axis or extruders, not not a linear axis with home switches. I never need to move them both at the same time, The typical use is to have one kind of cutter in one head and another in the other head. So I came up with an idea to switch all the signals from one head to the other. step, direction, spindle power, limit- and limit+ I am also writing my own custom host program so I can always make sure one of my Z heads is parked in a known position before I switch over to the other one. I am using two GPIO pins to select which head gets connected. This could be expanded to quite a few axis, as long as they don’t need to be moving simultaneously, it would work.
Since you mentioned you don’t need to make anything else while XYZ is moving, I think this solution could possibly work for you with just 1 smoothieboard.
however, I don’t know if you are using external stepper drivers or the divers built on to smoothie.
If you are wanting to use the drivers built on to smoothie, then your idea of running two smoothies together could defiantly work. Each smoothie would have it’s own Ethernet address or com port, and if you don’t need to really synchronize motion between the two smoothieboards, then all you need to do is send some commands to smoothie on com1, send an M400, wait for the ok from the M400 indicating that all moves are complete, then start sending the other commands to the other smoothie on com2 followed by another M400. you would need a custom host program to talk to the two ports like that… As I understand it, and I could be wrong, using USB serial would be a better choice for this, because if you want to stream with Ethernet you are supposed to send all your commands as fast as you can then count the OKs coming back until you get them all… but with USB you send one command and wait for ok… it might be easier to keep track with USB, but Ethernet could work too, you just need a counter to keep track of how many commands you sent, including the M400 increase the counter for each command then decrease it for each ok you get, when you get to 0 you can switch ports. If you need some help with a host program, let me know I have my own custom host program in the works, I do have both serial and Ethernet communication to smoothie working. I actually already have it talking to two serial ports because I planned on having a monitor for the non-usb serial on smoothie as well, but it could be adapted to do what you want to do. you just need to come up with a command to tell the program which port to communicate on… then fix it up so that giving a command to communicate on another port issues an M400 and waits for the buffer to be empty before switching ports.