Independant multiple Z axes

More
06 May 2021 17:17 #208135 by Chris1024
Hello Everyone

This is my first post here I hope its in he right place please correct me if I'm wrong.

I am building a CNC cutter much like a Zund which will have multiple Z axes which are removable. There will be 3 positions on the machine where you can plug in a Z axis unit. The unit could be a spindle a drag knife , a tangential knife or creasing wheel etc.

I have figured out how to do slave axes (the machine has two motors on the y axis). In the case of the Z axes what I would like is that when an axis is plugged in the axis will automatically home when the plug door is closed (interlock). The axes would be selected by tool number (1-9 position 1, 10-19 position two and 20-29 position 3) the tool offsets would be taken care of by the tool table entries.
ie M6T2 would automatically select the first z axis and move to position without re homing

I have figured out how to connect two 7I76 cards to get enough I/O for the 9 motors and loads of digitals needed for the plug and door interlocks etc

I know that multiple joints can be specified in the INI file for a particular axis and a bit of classic ladder can be used to enable or disable a pid block or step gen but I cannot figure out how the currently selected joint position feeds back to the axis.

I could experiment for hours with his but I thought I would ask to see if the is a simple explanation.

Thanks to everyone in advance

Chris

Please Log in or Create an account to join the conversation.

More
07 May 2021 22:09 #208260 by andypugh

I have figured out how to connect two 7I76 cards to get enough I/O for the 9 motors and loads of digitals needed for the plug and door interlocks etc


If you need 9 stepgens then you might need 2x7i76 but note that the 7i76 has a smart-serial expansion port for an IO card with (typically) 48 more IO points. However these are only serviced at the 1kHz servo-thread rate.

I know that multiple joints can be specified in the INI file for a particular axis and a bit of classic ladder can be used to enable or disable a pid block or step gen but I cannot figure out how the currently selected joint position feeds back to the axis.


It's probably simplest to configure with Z, U, V and W as the vertical axes. There are other ways if you really need each vertical axis to be controlled by a Z command in G-code.

So, that's the starting point, are there limitations on what your G-code can look like?

Please Log in or Create an account to join the conversation.

More
08 May 2021 09:15 #208291 by Chris1024
Hi

Thanks for getting back to me.

There was a typo in my oringinal text I have two 7i76E cards on the same ethernet port with a fast swich and it seems to work well. I also have some 7i85 cards to handle encoder feedbacks, and extra digital I/O if I need it. So no problems with I/O.

The reasoning behind having multiple Z axes is that all offests could be handled in the tool table (can you do this with U,V and W ?) and as you say the gcode would always use Z. I would be interested to know what method you would use to acheive this. Also I am writing a python script that takes a normal Gcode file and add the C axis moves to drive the tangenital knife / creasing modules and I would like to keep it to Z if at all possible.

Currently I am thinking of using classsic ladder to swap the signals to the joint and pid blocks around so that the two unused Z axes hold position at the tool change location. This would mean a lot of signal swapping, when you consider I would have to do the same for the three C axes as well, and it dosen't seem like a very elegant way of doing it.

So basically classic ladder would handle the signal swiching in real time and a python script would handle the initial homing and any Z module changeovers in user space.

Again thanks for the reply

Chris

Please Log in or Create an account to join the conversation.

More
08 May 2021 09:51 - 08 May 2021 10:05 #208293 by bevins
Replied by bevins on topic Independant multiple Z axes
IF your three Z axis stepper drivers are the same why not route the step and direction wires in the remap to the correct driver, rehome, apply the offset and off you go. I would probably wire in the three homes together and same with limits.

When tool 1-9 is the selected_tool then swap the step and direction wires via relays to the correct z driver.
I have a Biesse 346 with three spindles and the signals going to the spindle get redirected via relays depending on which tool is selected in the TxM6. I did it in python. Instead of rerouting spindle wiring you can reroute the step and direction signals. This assumes you only want one Z working at a time.

I have three spindles with one VFD. So if tool X from 1-10 is selected, I drop Spindle 1 and reroute vfd wires to spindle 1 and so on for the other two spindles. I also have a drill bank of 32 drills, I drop the tools when request via TxM6 and use the offsets in the tool table for all the tools.

Just a thought.

/EDIT: I just reread your post. You are swapping the Z out for a different Z module or all three Z's are on the gantry at all times?
If your swapping out the Z modules then this approach may not apply.

OK so you are swapping out the Z modules. So it would be like a manual tool change. TXM6 in the remap, wait for input, then change Z module press a button, then it will reoute the step dir signals to the drivers then apply the offsets.

just rambling now........
Last edit: 08 May 2021 10:05 by bevins.

Please Log in or Create an account to join the conversation.

More
08 May 2021 10:11 #208294 by andypugh

There was a typo in my oringinal text I have two 7i76E cards on the same ethernet port with a fast swich and it seems to work well.


It would probably be more reliable to have one 7i76E and then connect a 7i76-not-E to one of the expansion ports. That way there is only one ethernet packet per servo period, no switch is needed and net data flow through the port is reduced.

The reasoning behind having multiple Z axes is that all offests could be handled in the tool table (can you do this with U,V and W ?) and as you say the gcode would always use Z.


You can have UVW offsets in the tool table, but they apply to moves in U, V, W not in Z.

You can probably just run a single stepgen for all Z motors, and enable / disable the drives themselves so that only one moves.
It is probably safer, though, to run independent stepgens and keep the drives powered up and locked.

You might want to experiment with configuring the Z as a gantry, as that solves any homing issues (loadrt trivkins coordinates=xxyzzz)
Then each Z would be a separate joint, and they would home independently but all follow the Z command.

The unusual thing here is that you would disable (in HAL) the stepgen of all but the axes that you want to actually move.

For this to work you would need to do something with the stepgen feedback, either just short-circuit it, or make the F-error limits very large.

You would also need to configure to only allow tool changes at Z=0

Please Log in or Create an account to join the conversation.

More
08 May 2021 10:16 #208295 by bevins
Replied by bevins on topic Independant multiple Z axes

There was a typo in my oringinal text I have two 7i76E cards on the same ethernet port with a fast swich and it seems to work well.


It would probably be more reliable to have one 7i76E and then connect a 7i76-not-E to one of the expansion ports. That way there is only one ethernet packet per servo period, no switch is needed and net data flow through the port is reduced.

The reasoning behind having multiple Z axes is that all offests could be handled in the tool table (can you do this with U,V and W ?) and as you say the gcode would always use Z.


You can have UVW offsets in the tool table, but they apply to moves in U, V, W not in Z.

You can probably just run a single stepgen for all Z motors, and enable / disable the drives themselves so that only one moves.
It is probably safer, though, to run independent stepgens and keep the drives powered up and locked.

You might want to experiment with configuring the Z as a gantry, as that solves any homing issues (loadrt trivkins coordinates=xxyzzz)
Then each Z would be a separate joint, and they would home independently but all follow the Z command.

The unusual thing here is that you would disable (in HAL) the stepgen of all but the axes that you want to actually move.

For this to work you would need to do something with the stepgen feedback, either just short-circuit it, or make the F-error limits very large.

You would also need to configure to only allow tool changes at Z=0


Not a good idea pluuging stepper motors while drivers are on. I dont know if it matters if they are enabled or not.

Please Log in or Create an account to join the conversation.

More
08 May 2021 10:26 #208296 by andypugh

Not a good idea pluuging stepper motors while drivers are on. I dont know if it matters if they are enabled or not.


Definitely not, but nowhere did I suggest that.

Please Log in or Create an account to join the conversation.

More
08 May 2021 10:38 #208297 by tommylight

Not a good idea pluuging stepper motors while drivers are on.

Usually that will end up with drives in smoke, roughly 90% of the time. There are drives that can withstand that, but they do cost a lot and even then there are warnings all over the manuals to not do that.

I dont know if it matters if they are enabled or not.

It does, when disabled it is safe to play with the motor wires, but again, not always.

-Touching one of motor wires to the positive of the power supply will always end in a dead drive, enabled or not.
-There is one case when this will not be a problem on brushed DC servo drives, namely and exclusively if the drive is enabled and in a braking state where both of the upper side mosfets/igbt/transistors are on.

Please Log in or Create an account to join the conversation.

More
08 May 2021 11:32 #208300 by Chris1024
Wow thanks for all your replys!

I am using panasonic a5 servo drives for all the axes and they have high resolution encoders. This means that the step gens have to drive in the MHz region (using the differential outputs on the 7i76E) so I think swapping the electrical signals with a relay would be problematic.

I have tried to disable the step gens on the unused joints but it leads to a follwing error as the joint is still connected to the axis and is expecting to follow the Z commanded position (hence signal switching). I was wondering if there is a way to disassociate the joints from the axis and connect them only when required? I dont see a pin on the joint component that allows this, I don't actually understand how the axis is connected to the joint, I have assumed it is done internally from where the joint apears in the ini file.

Chris

Please Log in or Create an account to join the conversation.

More
09 May 2021 20:08 - 09 May 2021 21:15 #208411 by andypugh

I have tried to disable the step gens on the unused joints but it leads to a follwing error as the joint is still connected to the axis and is expecting to follow the Z commanded position (hence signal switching). I was wondering if there is a way to disassociate the joints from the axis and connect them only when required?


Yes.

Basically use a mux8 component.

connect mux8.in0 to the joint command / stepgen command pin. Connect the output to the joint feedback.
Then, with the mux8 in default mode there is a loop-back between joint command and feedback and it's all good.
Then connect the real feedback for each actual Z to the to mux8.N.in1, in2 and in4 and connect the mux8.N.sel pins to the same signal as the stepgen enable. Then, when the stepgen is enabled the motion system sees the actual feedback.

This assumes that only one axis is active at a time. is you have Z1 and Z2 active then the mux will pass through in3. You can make a decision about which feedack goes to MUX3, or leave is unconnected to force an error. Similarly for 5,6 and 7.

Note that there is mux_generic if you need more than 3 individual select bits, or you can convert bits to an int in HAL.
Last edit: 09 May 2021 21:15 by andypugh.

Please Log in or Create an account to join the conversation.

Time to create page: 0.182 seconds
Powered by Kunena Forum