Comparing in minutiae relative cylinder speeds

This is my first post and I’ve been a member for 2 minutes. I can't say that I have no concerns with my concept of Arduino but I am hoping that it might just be the vehicle to help in a way that other beers can’t!

I have some experience in programming and have some electrical/electronics under my belt but find that the programmer in me confuses the sparky and so feel like a complete beginner at times. I have no Arduino ‘stuff’ (2 days ago I would have associated it with some natural weather phenomenon) and so would like a feel of whether my ambition is too great with Arduino in mind and if not where to start. I love the idea of using old unloved parts that gather dust otherwise but am also aware that I might have to invest to get a reliable/useful result.

I have an interest in comparing the rotation motion (speed initially) of cylinders in a printing machine… why… because lines (imperfections) are clearly visible in the one-colour printed image and this testifies to differing motions of the cylinders concerned and/or potentially varying axis points (vibration or material thickness variation could in theory be responsible). The minimum requirement is to compare 2 cylinders and nirvana would be around 15. As I see it, the difficult thing here could be the resolution of the information required and the potentially ‘odd’ ratio of the relative RPM’s. I would like to conduct the monitoring throughout a cylinder perifferal speed range and for a number of cylinder diameters (so for the same perifferal speed setting, a cylinder that becomes half the circumference will have twice the RPM – but only one cylinder in the basic implementation of 2 could change diameter, though in the 15, there could be 5 that change diamater ).

Some figures:
Known-smallest-changeable-cylinder periferral speed: 3.048m (= 18.46 RPM approx. for smallest changable cylinder and 10 RPM for largest changeable cylinder)
Estimated-largest-changeable-cylinder periferral speed: 54.864m (= 332.31 RPM approx. for smallest changable cylinder and 180 RPM for largest changeable cylinder)

The required resolution of data is debatable in the way that the first picture of the Mars surface verified some important points. However, I don’t imagine that there would be a need to go beyond a reading per 10 microns perifery change.

Some less abstract specifics:
Known-smallest changeable-cylinder circumference: 6.5” (165.1mm)
Estimated-largest changeable-cylinder circumference: 12” (304.8mm)
A known constant-cylinder circumference: 11” (279.4mm)

In addition there is at least one axis that has no cylinder as such attached and where the RPM is perhaps a more realistic term.

For anyone who has been able to read this or even follow it thanks very much and of course I would be very grateful for feedback.

Thanks a lot.

I'm envisaging a solution where each cylinder/axis has some sort of position encoder attached which sends a train of pulses to the Arduino, and the Arduino determines the average pulse frequency over some time period and calculates a surface speed from that. Is that the sort of thing you're looking for?

I haven't quite figured out what units you're working in. What sort of range of rotational speed are you going to need to measure? How precisely do you need to know the speed, and how often do you need to measure it? (Average per revolution? Average per hour? Average per degree of rotation?)

One thing that I haven't muddied the water with yet is encoder versus resolver i.e. digital versus analogue. As I see it, a resolver is just a poor mans encoder but on the other hand, depending upon the AD converter, maybe not - because perhaps the precision (bits) of the AD converter can be selected to 'suit' the resolution required - I don't know.

Your view is how I see it too. Because the machine is imperial (hence the cylinder circumferences mentioned) the units are ‘naturally’ inches but of course metric is easier to deal with.

I’ll take a middle of the road scenario (4 axis) because it includes all different RPM’s ratios. For cylinder A, the constant relationships are:
A:B = 1:1
A:C = 88:52 (smallest cylinder), 88:96 (largest cylinder)
A:D = 1:4 (This is actually unknown and so this is an educated guess – though I intend to find out at the earliest opportunity)

As for how often does it need to be measured, well if I go for my ‘no doubt high enough’ scenario of 10 microns perifferal movement, at a modest machine speed (30 feet per minute), then for the various cylinders:

For all cylinder A, B and C: 10 microns pass in 0.0000656 seconds approx.
D which is actually just a drive shaft (treated as a cylinder earlier to try to make it easier), has an RPM relative to A of about 1:4 (A:D).

PeterH I hope that this is clearer now but if it is still not clear enough, please just say.

Thanks a lot 2Tricky

2Tricky.
Are you saying the cylinders actually can actually change their diameter? On the fly, by replacing, or just change in diameter from one to the next. Knowing the rpm with out knowing the present diameter wouldn't do much good, might need some kind of sensor on the diameter too.
Possibly a barcode like scanner on the actual cylinder circumference?
Just thoughts.
TomJ

Tom the cylinders don't change on the fly, they are changed from job to job by the operator and so this can simply (?) be put into a/the formula. I can see that this is a bit difficult to grasp from just my text but the long and the short is, except for one shaft, it is the periferal speeds that need 'watching'. This is of course intimately related to relative RPM's and so have little or no distinction from assessing a shafts relative RPM but never the less, the end of the rainbow is the peripheral movement.

As I said at the beginning, I suspect it is the odd relative RPM's that are potentially awkward (not forgetting the high resolution) but if it is a sticking point, we can talk about just one scenario such as a relationship of A:C of 88:52 and forget 88:96. I will be happy testing just one and hoping that some useful information comes back. Ideally I have in mind an oscilloscope plot (or data that I can plot later) where one cylinder can be seen to blip out of a relatively linear speed while others don't - this would indicate skid etc.

So the RPM's we now have are A:B as 1:1, A:C as 88:52 (although there is a lower denominator, it is based on gear teeth and so I've stuck with it) and if necessary we can forget the shaft (which as I say I reckon is about 1:4 for A:D and I'll check ASAP).

After writing the above, I realised that I have presented it wrongly - the correct A:C RPM ratio is 52:88 whilst the others are still fine.

I hasten to add, if the ratio 52:88 is horrible (and I suspect it is) I can make it simpler such as 64:88 for instance - I suspect it depends upon finding suitable denominators for encoder/resolver resolutions.

Tom thanks for your input 2Tricky

2Tricky:
As for how often does it need to be measured, well if I go for my ‘no doubt high enough’ scenario of 10 microns perifferal movement, at a modest machine speed (30 feet per minute), then for the various cylinders:

For all cylinder A, B and C: 10 microns pass in 0.0000656 seconds approx.
D which is actually just a drive shaft (treated as a cylinder earlier to try to make it easier), has an RPM relative to A of about 1:4 (A:D).

PeterH I hope that this is clearer now but if it is still not clear enough, please just say.

Thanks a lot 2Tricky

I understand that the significant thing you're trying to measure is the peripheral speed of the cylinder i.e. the tangential speed at the surface. What I don't understand is what 10 microns has to do with that. Perhaps it would help if you gave some idea of what the overall problem is.

I'm guessing that these rollers are somehow involved in moving media during a printing process and that different rollers are intended to have an identical surface speed (or perhaps, a surface speed that is not identical but is a specified ratio).

If the speeds were not controlled exactly correctly then I imagine this would cause two cylinders to go 'out of phase' over time and I think this is what you're trying to detect. Is 10 microns the minimum phase misaligment (slip) that you're trying to detect? If so, over how long is that slip measured? Per second? Per revolution?

By the way, please note that 'perifferal' is not a real word. :slight_smile:

PeterH that should of course be peripheral. Your first two paragraphs are spot on. The error develops (and disappears) quickly and is not accumulative because the various cylinders are mechanically ‘locked’ and so any error is because of those gears and/or a changing axis point and/or physical ‘give’ in the system as a whole (by changing axis point I refer to give in the shafts on which the cylinders run – gears trying to push them apart etc).

10 microns then, refers to my own guesstimate of a resolution that must surely be sufficiently zoomed-in to provide insight. It neither refers to the extent of the error in the motion when comparing any two or all of these peripheries nor the visible printed imperfection. In fact the printed imperfections can be around 6mm (@ 30 fpm = 0.039 approx. seconds).

Thanks PeterH - 2Tricky

2Tricky:
In fact the printed imperfections can be around 6mm (@ 30 fpm = 0.039 approx. seconds).

There is a huge difference between 6mm and 10 microns and I still haven't got my head around what resolution and frequency of measurement you're trying to achieve. Is 6mm the discrepancy between the distance moved on the surface of two cylinders? From your last post I get the impression that this is more like jitter / backlash / play rather than slip (sustained gradual difference in position).

If that's correct, then over what sort of timescale does this jitter occur and how small a jitter are you aiming to measure?

I'm starting to imagine a solution based on a couple of optical mice pointed at a test pattern attached to the surface of each roller, but I'm still not sure I have understood the problem correctly, and every time you mention 10 microns it worries me.

Once you have got a number that shows there is jitter, what are you going to do with it? I guess you want to know what the source is so that you can eliminate it. In that case maybe you should be looking for backlash in the mechanical drive system and measuring eccentricity and radial play of the rotation parts. Is the drive mechanism loaded? If you want to define position/speed accurately you will probably find you need to apply a small load to take out the backlash - for example a light brake on each output drum to take out angular backlash, and a lateral load on each bearing to take out radial play. (If you've got belts/chains/gears etc involved, these will already be applying lateral loads so that may be taken care of).

PeterH:

..I get the impression that this is more like jitter / backlash / play rather than slip (sustained gradual difference in position).

If that's correct, then over what sort of timescale does this jitter occur and how small a jitter are you aiming to measure?

I think you are right to think that this is the likely problem. The 6mm approx max printed imperfection is how the error shows to the naked eye and should not be taken as testimony to either the distance or duration during which the positional error exists. The trouble is, these cylinders intersect a bit i.e. the surfaces (as in plate particularly and paper to an extent) are soft, their natural relationship is never simply tangential and cannot be so because paper is not mill pond smooth and the same goes for ink with its varying viscosities and the need for a certain surface tension to the substrate (which can be synthetic) for instance. Therefore any momentary angular blip in what might otherwise be perfect motion, can appear protracted. This is very difficult to quantify because as you have mentioned, eccentricity also has a part to play. Cylinders A and C have gears that mesh directly and already use sprung anti-backlash gears and cylinder B has natural resistance caused by drag. The rest of the machine is really pretty tight I believe.

I'm starting to imagine a solution based on a couple of optical mice pointed at a test pattern attached to the surface of each roller, but I'm still not sure I have understood the problem correctly, and every time you mention 10 microns it worries me.

I believe that the source and duration of the mechanical error as opposed to the size of visible artifacts, is as long as a bit of string (but short!) and so if 10 microns doesn't do it, then I'm not sure what will. It's funny, I came across Arduino whilst looking for ways to hook up mice/mouses but in the end wondered whether I was asking too much when I had 10 microns in mind - I'm open minded and have become aware of the optical versus laser versus encoder rs232 debate but am aware that there are some 'pretty high' resolutions available but at what cost - I don't know.

Once you have got a number that shows there is jitter, what are you going to do with it?

I would really like to view the data in real time as superimposed waves on an oscilloscope because I would like to apply 'influence' here and there and monitor the effect. If I have data, I'll simply plot it until something emerges that indicates where to next focus.

N.B. Radial play is not going to exist in cylinder 'A' which is under highish radial load and has exceptional TIR or much for 'B' which I guess has no more than 1/2 thou but is also under load anyway. That said, for a small cylinder 'C' with a big solid plate mounted on it, there is likely to be no radial play whilst a bigger one with fine print might have around 1/2 thou.

Thanks peterH for your interest - 2Tricky

To look for radial play and lateral deflections in the shaft you could use a dial gauge with a roller tip running on the outer surface of the cylinder. Although it would be nice to be able to quantify that, I think that the deflections needed to produce 6mm worth of jitter would be very noticeable to the naked eye.

An ordinary optical mouse typically has a resolution of several hundred dots per inch. Since these are freely available at effectively zero cost, I'd be inclined to start with one of these and see whether it's possible to get a usable indication of cylinder surface movement. If there is a problem producing anywhere near 6mm worth of jitter then it would be immediately obvious from a sensor with a resolution of a few hundred dpi.

I don't know what the maximum speed is that an optical mouse can register. Perhaps you will exceed that. I suppose the only way to find out is to give it a try. Laser mice don't cost much (US$10?) and have a resolution of a couple of thousand dpi which is getting towards the 10 micron resolution you asked for. But if there is a speed problem, it will probably be worse with a laser mouse.

In the simplest scenario, you would use write a sketch using the Arduino OptiMouse library which just produced an output pulse every time the mouse reported a step move. Then connect that digital output to a picoscope or similar on your PC which captured and displayed the pulse train.

I think you will get more useful information (and avoid wading through a mass of data) by putting the jitter analysis inside the Arduino - monitor the movement signals from two mice, differ the movement events to derive relative movement and report when the relative position changed enough to matter. This has the advantage of being solve entirely within the Arduino so you have less technology to obtain/deal with.

PeterH I've tried our fine dial gauge before now for just this reason but with poor results because the gauge is perhaps too sensitive to general vibration. The cylinders have several lateral scribe marks across them which upsets the apple cart and some of the machines functions inhibit use of a gauge.

I like what you are saying about a couple of mice but I have no idea about Arduino. I would be grateful for your view on hardware requirements for the 'Arduino OptiMouse library' route and hardware requirements for your preferred route too. Would they both need an Arduino board or...and which board might that be?

Thanks a lot - 2Tricky

Is there a fixed reference somewhere near the surface of the cylinder that you can use to position a fixed pointer just above the surface of the cylinder? Position the pointer as close to the surface as you can manage, so that the cylinder just barely avoids scraping it. If the cylinder is flexing towards the pointer it will make contact. Perhaps you will be able to see/hear that directly, but if not then apply some sort of colour to one part so that it leaves witness marks on the other. (Sorry, I can't visualize the physical setup well enough to give a less vague suggestion.)

I suspect that I can find a cylinder that has just one lateral scribe and persevere until I get a TIR but I admit to prefering to focus on speed fluctuation (as already brain stormed) because I believe the TIR and/or radial play is pretty small and the machine is generally well made and pretty 'stiff'. Also: If TIR and/or radial play were a main factor, evidence would come in a pattern that would be expected to repeat with each revolution to a large extent but this does not really happen (incidentally the cylinder that I refer to is 'C' - the one that the operator changes) and there is a lateral load on each bearing to take out radial play - in the form of a spring.

N.B. The gear on cylinder 'A' is Agma grade 10 which is a good ground gear and so should not be producing its own pattern of errors (I hope).

Thanks PeterH - 2Tricky

2Tricky:
I would be grateful for your view on hardware requirements for the 'Arduino OptiMouse library' route and hardware requirements for your preferred route too. Would they both need an Arduino board or...and which board might that be?

I haven't used the Arduino Optimouse library, but it's described here and doesn't seem to have any requirements for any particular Ardunio - if this is your first Arduino project I'd suggest starting with a Uno just because it's the most widely known and used variant. The Uno also gives you maximum flexibility for using add-on shields later if you find you need to go down that route. And of course you will need an optical mouse per cylinder that you want to monitor, and you'll need to look inside the mouse and find what chip it uses and track down the data sheet for that chip to find which pins do what.

Thanks for your help with this PeterH, this is the page that first alerted me to Arduino and our conv. has re-whetted my appetite for an inexpensive route - maybe I should get a Arduino reference book to fill in some blanks such as interfacing it...

In the mean time I also dug up reference to the Windows Raw Input API that looks interesting and I have some experience that should help get started with it. In the particular example scenario outlined, two mouse were considered and so maybe I could get that working in Excel for example where I have VBA experience.

As ever I'll keep my ears to the ground but continue to look around - cheers 2Tricky

My first thought was to use a strobe looking at the cylinder ends, but that would really only allow you to compare cylinders with the same diameter and rpm.

Also the comment

The error develops (and disappears) quickly and is not accumulative because the various cylinders are mechanically ‘locked’

, seems to rule it out. I am surprised the error disappears.

If the defect is 6mm long then I think you have to try and work back from that to try and figure out roughly how long the discrepancy in cylinder speeds must have existed to create the defect. That will tell you how frequently you need to measure the cylinder speeds to be able to "see" the discrepancy.

Actually that takes me back to strobes again, though this is probably not practical. Could you put bands on the edges of each cylinder with graduations marked on the bands. The graduations would be spaced according to the diameter and rotational speed of the cylinder so that the space between marks represented the same surface speed. If you shone a strobe on the bands they should all freeze and maybe you will see bands "kick" as the problem happens. You might use video perhaps running at high speed to capture the kick.

Not an arduino solution I know and it depends on being able to fit bands to rollers and get a clear viewing angle at their surfaces so I am probably just gibbering.