Show Posts
Pages: 1 2 [3]
31  Using Arduino / Project Guidance / Re: Uno, signal conditioning and an optical sensor on: September 23, 2012, 03:44:24 pm
My reference document is from here:, where is your's?

There is only an output voltage (nothing about current output), so if in doubt I'd use the voltage divider.

Here's mine:

Is this likely to be OR can it be correct given that your reference states Volts...

I've been trying to measure the analogue outputs to no avail but am wondering whether the cheap transformer I'm using (and lack of knowledge) could be leading me astray. The multimeter shows this 12V unit giving out 18V and I'm wondering whether its not very smooth.  If the Sick does vary current in line with different greyscale values detected, what is the implication?

A few hours later: Have spoken to Sick and it is being verified.

Result: Sick confirmed spec should give voltage not current.

32  Using Arduino / Project Guidance / Re: Uno, signal conditioning and an optical sensor on: September 20, 2012, 02:22:17 pm
QA probably means the pin. Often in electronics outputs are labeled 'Qx' (Qa, Qb, Qc etc.)

Thanks Karma.  I'll take a look at the feedback and have a play.  Have to say I'm nervous about my reference being Current and Pylons being Volt (!)
33  Using Arduino / Project Guidance / Re: Uno, signal conditioning and an optical sensor on: September 20, 2012, 02:10:24 pm
The product description I found on the internet says analog output on QA is 0.15...6V, so a simple voltage divider (2 resistors) to an analog input should do the job.

Pylon, how does this relate to the current reference that I found (" 0.15 mA ... 6 mA")...and how does that fit into the picture...  What does QA mean?

34  Using Arduino / Project Guidance / Uno, signal conditioning and an optical sensor on: September 20, 2012, 01:32:39 pm
Hello, I am new to both Arduino and electronics.  I have an Uno R3 and the need to use a SICK NT6 optical sensor to recognise changing greyscale.  The documentation uses the expression "Analog output QA: 0.15 mA ... 6 mA" - the "QA" of which I have Googled to no avail.

I've tried to figure out how (using umpteen different tutorials) to view the problem of connecting this satisfactorily to the Uno but am at a loss. 

This is what I think I know:

The Uno can take between 0V and 5V at up to 40mA.
The SICK is permitted to use anything from 10V and 30V DC to power it.
I've tested the SICK in a scenario where I showed it black and then white and using a digital multimeter the output varied between roughly 0.6V and 1.6V (I thought that I had seen a larger Voltage range in a spec somewhere).

I would be grateful for a structured approach to how I should properly pull this problem apart.

Many thanks.
35  Using Arduino / Project Guidance / Re: Comparing in minutiae relative cylinder speeds on: August 14, 2012, 02:25:31 am
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
36  Using Arduino / Project Guidance / Re: Comparing in minutiae relative cylinder speeds on: August 13, 2012, 11:37:34 am
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
37  Using Arduino / Project Guidance / Re: Comparing in minutiae relative cylinder speeds on: August 13, 2012, 10:21:00 am
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
38  Using Arduino / Project Guidance / Re: Comparing in minutiae relative cylinder speeds on: August 13, 2012, 07:57:38 am

..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
39  Using Arduino / Project Guidance / Re: Comparing in minutiae relative cylinder speeds on: August 13, 2012, 03:20:29 am
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
40  Using Arduino / Project Guidance / Re: Comparing in minutiae relative cylinder speeds on: August 12, 2012, 11:23:00 am
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
41  Using Arduino / Project Guidance / Re: Comparing in minutiae relative cylinder speeds on: August 11, 2012, 11:42:46 am
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
42  Using Arduino / Project Guidance / Comparing in minutiae relative cylinder speeds on: August 11, 2012, 05:15:06 am
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.
Pages: 1 2 [3]