Motion Control

[Rudolph]

 For Controllogix V17 and K6K/K7K.......

Has anyone tried to SSV the Convesion and PositionUnwind to compensate for a change in the mechanical drivetrain?  Ideally I would like some code that takes an integer fraction ratio and calculates the appropriate numbers much like the Calculate.. button does on the Drive/Motor tab in Logix.  The problem I have found is that SSV to DriveResolution is not an option.  I don't know of a way to avoid potential rounding error or non-integer Conversion and PositionUnwind numbers without changing the DriveResolution.  Any ideas??

Rudolph

[NorwichUK]

By change in mechanical drivetrain - do you mean sizepart change, or chain 'stretch'.

The conversion and unwind is relatively easy to do via SSV, just need to take care that your drive resolution is such that you still get an exact integer of motor counts for the unwind. Its not important if you have recurring number for your conversion constant, but the unwid has to be exact. If your new gearing fractions is such that your unwind results in a recurring number, then the only option is to change the drive resolution to take this out. If you are an OEM, you have a good idea about what all the gearings / lengths  are going to be, and can then deduce a drive resolution number that can take care of all the division by '3's etc such that you still obtain an exact integer for the unwind. An example here is if you know all possible combinations result in divisions of say 3, 7, 11 etc then pick a drive resolution that has at least 3 * 7 * 11 as a factor such that any divisions by these prime numbers still give an integer

Can you give an example of your drive resolution, gear in, gear out, final drive circumference (or # of teeth on a sprocket), and the units you require? Best example to give would be with your particular setup.

[NorwichUK]

Here is something you can try – though you will need to test this first with your particular numbers as roundings can take place depending on the size of numbers and the order of the maths.

Some definitions:-

MotorResolution – Exactly what it states, and is the number that is entered on the drive tab.

Gear – Is the number of turns the motor has to make such that the drive shaft makes 1 rev

Drive Circumference – for a sprocket,  its the number of teeth x  tooth pitch.

Pitch – The length of the rotary axis in its engineering units.

Example:-

In the example below, the gear is 5 turns of the motor shaft equate to 1 turn of the drive shaft – make sure you take into account all the linkages in between the motor shaft and the final drive shaft.

Some numbers:-

Motor Resolution =8000, Gear =5, Drive Circumference = 12”, Pitch=6”

Unwind = MotorResolution / DriveCircumference * Gear * Pitch

Unwind = 8000.0 / 12.0 * 5.0 * 6.0

Note – the gear may not be an integer (it could be a fraction like 5/2 – 5 turns of the motor shaft for 2 turns of the drive shaft). Make all your variables floats to start with – the maths will perform faster.

The order of the maths can be interchangeable – you will need to determine whats best depending on the magnitude of your numbers. If you have say something like 10,000,000 for a motor resolution, best reduce this first with a division before a multiplication makes it even bigger and overflows the float precision.

So looking at the maths and the order of it above – pick a motor resolution that all the drive circumferences and any fractional gearing can easily divide into it by – and you are then assured of an exact integer for the unwind. You can test for this being an integer by converting the float result to an integer, and then find out what the difference is  

i.e IntegerError := ABS(FloatUnwind – DintUnwind) ;

If the result is < say 0.000001, then the small fractional part is just float rounding and you do indeed have an exact integer. I recommend you don't skip this test!

ConversionConstant  := MotorResolutiuion / DriveCircumference * Gear

Note for Rockwell People - it there any chance of making the LongInts fully functional such that they work in any maths, and data promotion takes place like it does for DINTs, REALs, SINTS etc when they are mixed up in expressions?

[Rudolph]

NorwichUK,

 Thanks for your replies.  We are an OEM and we do know the exact drive ratios at the time the machine ships but the end users will occasionally change products which may result in a change in the mechanical ratios.  Unfortunately we do not know what this ratio will be ahead of time.  Perhaps it would be possible to narrow down the possible ratios and deduce a DriveResolution that will work for all of them.  I fear that this method will eventually fail do to a ratio change not included initially.

For example, lets look at a web printing application where a rotary print roll with an integer number of "patterns" around its circumference is connected to a servo motor.  The conversion and unwind will be set to units of "patterns".

Drive elements in order from motor to load. 

Gearbox:          7:1

Belt Drive:        37 tooth driving a 122 tooth

Print Roll:         3 patterns around

I would normally enter this a 854 motor revs / 111 patterns to calculate DriveResolution and Conversion.  This works great until we get a call from a customer saying that they changed the print roll and belt drive ratios.

Drive elements in order from motor to load.

Gearbox             7:1

Belt Drive           37 tooth driving a 130 tooth

Print Roll:           2 patterns around

 While it is certainly possible to find a DriveResolution that would work for both cases, currently, we don't have any information of what the ratios might be.  If I cannot find a universal way of handling all ratios I will go down the path of limiting which ratios will be allowed.

I still have one idea left on how to handle this for all ratios and maybe I will post it for discussion once I figure out how to explain it.

Rudolph

[NorwichUK]

Here’s my thinking, and at this stage its easy to get things upside down – so there may be errors!

If you recommend end users change the large sprocket only, then you should be able to cater for most of the likely changes with a Motor Resolution of:-

5 * 7 * 8 * 9 * 37 = 93240

This number is divisible by all numbers ( 1 , 2, ... 10) * 37

The conversion constant is then the number of pulses / unit travel = 93240 * 7 * 122 / (3 * 37)

The unwind in this case is the same as the conversion constant, as the unit travel is 1 pattern. So if you spec that only large sprocket changes are permitted, you are covered for print heads  from 1 to 10 patterns (maybe more and you could expand this number for patterns that it doesn’t cater for) and an unlimited change of the larger sprocket – as this is in the numerator and will always still give you an exact integer for the unwind.

Like I stated, these things are easy to get upside down and I haven’t double checked anything here.

Unfortunately, you can’t write to the Motor Resolution from your program (you’ve only just been given access to read what it is via the firmware). This is not ideal to cater for an infinite change of everything like you rightly stated.

Let us know what the other solution was - I'd be intersted to know that as I do this sort of thing all the time and would welcome another approach.

[Rudolph]

NorwichUK,

I agree that your solution could work.  It is likely reasonable that only the larger sprocket and number of patterns will change on a given machine.  On the next machine it is possible that the gearbox or small sprocket will be changed.  This would require adjusting the DriveResolution for each machine (which is easy enough, the hardest part will be making sure whoever does it realizes the significance of that number).

My possible solution to allow near infinite ratio adjustments for an application like this.....

I am somewhat inventing this as I type so bear with me.

 When the Master travels one product the Printer needs to travel one product.  In our current system the conversion and unwind are set so that the engineering units are per product however this doesn't have to be the case.  For this solution I want the conversion to be in motor revs.

Constants:

MasterConversion = 10000 for sake of discussion

DriveResolution = 100000 for sake of discussion

Conversion = DriveResolution 

Variables:

RatioMotorRevs =  user adjustable integer

RatioEngineeringUnits = user adjustable integer

PositionUnwind = DriveResolution * RatioMotorRevs (Set by SSV)

Code:

In the MAG

MasterCounts = MasterConversion * RatioEngineeringUnits

SlaveCounts =  DriveResolution * RatioMotorRevs

This will allow for all integer math.  The biggest problem I see is fitting the MasterCounts of the MAG in the 5 digit limit.  That concern would be reduced if I can always set the DriveResolution the same as the MasterConversion.

Using the current axis position, RatioEngineeringUnits, and RatioMotorRevs I can convert the position to the desired engineering units of Product.

Position = Axis.ActualPosition *  RatioEngineeringUnits / RatioMotorRevs

I am not convinced this is the proper solution but it appears it would work.

Rudolph