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