Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: sx3 on January 14, 2019, 11:57:50 AM
-
Hi,
Is it possible to set an OB axis to roll-over?
And in some "easy" way keep track of its position, if once homed? Trying to understand how I can make a script for a rotating tool turret and keep track of its position.
-
I set up an OB Axis a while back to do some testing (which I am about to implement on a mill). You can set a DRO to read the OB Axis position.
I don't know if you can set it to roll over; once I get this the spindle mounted on this mill and get the wires nestled into place then I am going to start messing with the Tool Carousel motor again. I plan on making it an OB axis to prestage my tools. Having the ability to roll over with it will be nice.
-
Alright, would the DRO display Degrees, inch/mm or counts/step? Since OB axis can only be jogged in position is would be really nice if it was possible to let it roll over at 360 degrees.
I was afraid that I have to write the counts/step in a register then read out and calculate positions. If that would be the case I might consider letting the M6 Home the axis at every tool change to easier be able to send it to the next tool. However, that would be far from optimized.
What ETA do you have on your project? would be nice hear about your progress!
-
Doing the calculations in thr PLC would be easy enough and quick. I litterally just tensioned the belts on the spindle. Going to get it going tomorrow and then hopefully start moving the tool carousel. Going to spend a little time getting the grasp of the OB axis again.
-
The DRO would be in whatever you set the motor up to be. Counts per unit. It if is rotary, how many counts per revolution is what you would put in the counts per unit field for the motor.
Then there are update and modify scripts (See the GUI manual on how to use them) that can be attached to the DRO that reads tracks OOB axis' motor position. The rollover count be handed in those scripts. The axis would have to be homed first, but you probably want to do that anyway. Since you would move the tool turret incrementally (so many degrees per tool pod), it would be easy to keep track of what tool you were using.
I can't wait to see what you guys come up with! :)
Steve
-
Thanks @smurph,
I'm a real rookie when it comes to programming, and making a ATC work might not be the easiest or smartest thing to start with. However I'm comitted and I will make this work!
There are some elementary stuff I'm yet not aware of, but I think the pieces will fall in place sooner or later. :)
- Counts per revolution in the config, would that be for the motor-shaft or the tool-turret? Our turret is geared/have ratio.
- We will home the axis, when referencing the machine. But not in the middle of program (I guess this was what you meant).
I looked in the manual and found the examples and some questions arised:
1. In the example, where in the script is the Axis defined? Can't really figure out where I could define it's all about the OB2 i.e?
Or is that simple as when I assign the DRO Code of OB2 for the DRO in the GUI, the script that goes inside DRO will keep track of where it is and what to update?
2. If I just Copy&Paste the example update script, then the DRO will update if my M6 script or if my Signal script in event of manual button push jog the OB2 axis?
I can't really see that I would need to modify the example?
-- Example encoder update script.
local inst = mc.mcGetInstance()
local val = select(1,...) -- Get the system value.
val = tonumber(val) -- The value may be a number or a string. Convert as needed.
local name = select(2, ...) -- Get the control name. It is always a string.
val = val / 1024 -- convert the encoder value to a decimal (assumes 1024 counts per unit).
return val -- the script MUST return a value, otherwise, the control will not be updated.
3. Now to the modify script, I guess this is where I should "zero"/roll over the axis in event of >360 degrees?
I'm in the right direction with this code? (modyfied the example a bit, haven't debugged it though.)
local inst = mc.mcGetInstance()
local val = select(1,...) -- Get the user supplied value.
val = tonumber(val) -- The value may be a number or a string. Convert as needed.
local name = select(2, ...) -- Get the control name. It is always a string.
if val > 359.999 then
val = 0
end
val = val * 1024 -- convert the decimal value to encoder counts (assumes 1024 counts per unit).
return val -- the script MUST return a value, otherwise, the encoder register will not be updated.
-
Anyone have tought about above posted update/modify scripts? :)
-
I would like to make a rollover axis as well. Once my carousel gets to 20 I want it to go back to 0.
I really don't know where to start with this myself.
I will look at it more tomorrow, but the examples in the manual aren't very clear to me.
-
I agree, I think the update script is good to go as the exmaple.
As the DRO reads counts from the encoder, the update script just translates the count to degrees (if counts in motor setup = 1 turn on the carousel) and present the new/readble value that correspond with the metric/imperial system in the DRO.
The modify script however, I think it will manipulate the encoders memory and in our case this should be the place to reset the counts once we've rolled over.
Hope @smurph can clarify this to us :)
-
Ok, and encoder isn't a great example for the modify script because typically you only read an encoder. But here goes...
The update script is for when the encoder updates the DRO. So you have the ability to translate the encoder's value to what you want to see. I think we are all on the same page about this one.
The modify script is to do the reverse when the user (you) edit the DRO. Convert the displayed (or typed in) value to encoder counts. But like I said, unless you have hardware that will let you set the encoder value, it doesn't fit.
But you could use the encoder reading, plus the value of another register as an offset if you wanted. Then using the modify script to set the offset register so that the DRO reads whatever you put in it. :)
update: encoder value + offset register value -> displayed value.
modify: input value -> encoder value + offset register value. (only the offset register value is modified because the encoder is read only.)
Steve
-
I guess I'm just having a mental block on modify and update scripts. I cannot get my head around how they are supposed to work.
-
Well... get over it already! :)
Just think of the scripts as translation scripts. Update translates the system value into the human readable value. Modify translates the human value that is input into the DRO into the system value.
The distinction between update and modify pertains to who/what is changing the value of the DRO. The update script is run when the system changes the value of the DRO. The modify script is run when the user clicks on the DRO, changes the value, and then hits enter.
Maybe that helps? It is about as clear as mud, I know. But once you see the light, it will make sense.
Steve
-
Oh man, that makes sense.
I don't want to enter any information into the DRO, so I will use the update script. I simply want to update the OB1 axis position.
When it goes over 20, I want it to start back at 1. Is that possible to do, alter the OB1 Axis Position? If not, it is fast enough just using the C Axis, but I was really hoping I could figure out how to allow it to use the fastest route along the Carousel to get to a tool. You know, 19 ---> 1 is only 2 tools away instead of 18.
I've helped a buddy write a PLC ladder that finds the fastest route along the carousel, so I have most of the math heaving lifting done if I have to resort to using Incremental moves, but that would absolutely require me to be able to update the current position of the OB1 axis.
-
if I have to resort to using Incremental moves, but that would absolutely require me to be able to update the current position of the OB1 axis.
Why? Incremental means you do not care where it is or where it is going. You only care that it goes the distance you tell it to.
The only time you need to go to an abs position is after referencing to line up with whatever slot you want. After that, incremental is all you need.
That previous line is not right. You could go to an ABS position after referencing but even that would still be better being an incremental move. I'm not sure the OB position is updated even after referencing. If not, it's still no problem. The first move will always be the same distance assuming of course it can reference with a reasonable degree of repeatability. If it can't reference with that reasonable degree of repeatability that's the first thing that needs to be fixed.
You know what tool number it is at. You know what tool number you want to go to. Just do the math. Determine how many slots to go and what direction. Now do an incremental move of that distance in that direction.
-
Brett is right. Once the carousel is homed, and brought to the first pod (either ABS or INC move), the distance between each pod on the carousel is going to be the same. You don't have to do anything except move incrementally forward or backward from there. You can keep track of the current pod in the code.
Say you have a 20 pod carousel that has 3600 counts per rev. The pods will have 180 counts between them. Pod one is 20 counts positive from home pos.
1. Home (motor is now at 0)
2. Got to pod 1 (20 counts positive offset from home). Set the pod variable. pod = 1;
3. Calc what it takes to move to to pod 10. Do shortest path math (say we go positive for grins).
4. Move to pod 10: 9 * 180 = 1620. jog incrementally 1620 counts. set pod var to 10.
5. Calc what it takes to move to to pod 8. Do shortest path math. We are going to go negative this time.
6. Move to pod 8: -2 * 180 = -360. jog incrementally -360 counts. set pod var to 8.
etc...
And we never have to even look at an encoder. This is how my Geneva drive works on my carousel tool changer. No encoder what so ever on it. Just a pod #1 switch. It is all math from there.
Steve
-
Pieces are falling into place. :)
About setting Pod var, is this somehow going into a register or will Mach remember this var when promting it during next tool change?
Would it possible to set pod var to 1, during the home/reference action so that the variable always have a number during the first tool change?
-
Pieces are falling into place. :)
About setting Pod var, is this somehow going into a register or will Mach remember this var when promting it during next tool change?
Would it possible to set pod var to 1, during the home/reference action so that the variable always have a number during the first tool change?
Well, lots of ways it could be done. You could just create a register and write to it when you move and read it to determine how far to move. Or, one of the slicker ways to do it would be to have the plc script monitor the position of the OB axis. For every so many steps in this direction add one to the current pod #, for every so many steps in the other direction subtract one pod from the current pod #. In between positions it could read pod 0 or "No Pod". This way if say an estop was activated while the pods are rotating you still know where it is or you know you need to reference it to continue. Endless ways to make it work. Even more ways to make it work very well.
It's a logic puzzle. Enjoy solving it. Map out every single step and all the possible ways to do each, what could go wrong during that step to make it fail and what happens if it does fail. Do you throw an estop and pop up a message box? Does it just automagicly reference and start over from there. Endless possibilities. It makes you think but that is the fun part.
-
And we never have to even look at an encoder. This is how my Geneva drive works on my carousel tool changer. No encoder what so ever on it. Just a pod #1 switch. It is all math from there.
Steve
What is on our Milltronics is a side mount tool carousel, OEM it had a servo on it; so we just replaced the servo.
I have the motor calibrated so that 1 revolution reads out 20 positions. Is it better to use motor counts or axis position, or does it matter as long as it is consistent?
It's a logic puzzle. Enjoy solving it.
Logic is all it is; like I mentioned in an earlier post, I helped a couple of friends retrofit an old Hurco and helped them come up with the logic of finding the shortest path to the tool, I'll just steal my work from that PLC ladder and convert it to LUA. A logic puzzle is exactly what this is, and it's quite fun! =)
I will still need to play around with the update script now, I haven't been able to work on it more.