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.