I am back project time again

[blueyedpeter]

The project this is why.

I actually Own a couple of plc,s and like i have been stating , code writing i am weakest at , my programs usually look like a hard wired attempt there's nothing fancy or stylish about how i write .

I know i have been vague about where i am going with this because i would have dribbled on far to long and you all would have written me off as a crazy with a lap top.

And granted i am starting to wonder if i have drooped a cog in trying to automate an exercise bike .

It would be far easer to go and buy the thing they are called amongst other things computrainer and sell for about $2400 US .

As for details it is rather simple i cant mount an encoder on the back wheel as it would get up to speeds of 6000 rpm , so a single prox input will do fine .

The other input is mounted near the rider, at the pedals and will monitor speed of the pedals , the maximum speed there is around 130 rpm

Things that will be measured include speed , distance , average power out put of the rider , there will be three load ranges hi med and low , there is a second load device that will respond to an analogue output to drive the second load device from 0 to 100 %, the rider will be able to chose auto or manual programming , from flat rides to hill climbs and circuit style programs .

The manual selection of effort will be achieved with a small push button on the handle bars ,there will be progressive indicators on the handle bars showing status of the program and remaining time left in the ride , and it will be displayed in kilojoules and to add insult to injury your effort at the end of the training session will be compared to how many candy bars or Big Mc burgers you just burned off on you training session .

So i am sorry if was a little vague but i thought i might need to brush up on my basic code writing skills and the first mole hill to get around is an accurate speed reference from a single prox input later to derive a method of ratios between the cyclist pedal speed and the back wheel speed .

Because of the lack of inputs just about every maths equation is going to be derived from these two single inputs there will be a lot of counting and comparing being done in the back ground .

And a small 6 inch panelview will be used to tell the rider were the program is up to with graphical and data type information .And the reason in am doing such a project is because i actually like the idea of modern automation and driving my self mad in the process and i don't like to give up on anything no matter what the cost .

MY manta is never give up. and if you need proof of my mental state i can send you email pictures of the status of this project in my garage .
So on a final note if this only serves to confuse the picture i am very sorry, for any confusion made.

 

[GlennA]

That sounds like a very ambitious project. The advantage of using a PLC is you can start with a very basic program and add features later. On another note = do you have all of the software to program the PLC and the HMI ? If you have to buy software, the project cost will increase quickly.

 

[Clay B.]

I would try to have more than one pulse per rev. You are going to find even with alot of math you are going to get oscillation. If you have a wheel you can make multiple flags so you have more than one pulse. Also make the pulses an even number and space them as evenly as possible. A sprocket can be used buy simply turning down the points and knocking off every other tooth so you have some off dwell time on your sensor. This sprocket can be mounted on the other side of the tire away from the chain.

One gotcha when making what I like to refer to as a "redneck" encode is pulse transition. When the sensor transitions this has to be taken into account. People tend to fixate on pulse width and forget about the change of state part.


Also some kind of filtering or averaging will be required. In a perfect world speed would be a constant, in reality it isn't and measuring it for rate is always a hurdle.

I think your project sounds cool and while yes you could buy something already built, doing it yourself always pays off, if in nothing but knowledge.

 

[Lancie1]

. . .the first mole hill to get around is an accurate speed reference from a single prox input [and] later to derive a method of ratios between the cyclist pedal speed and the back wheel speed.

Why is this ratio important? Can the cyclist quit pedaling and coast for a while, as on a real bicycle? If so, the speed ratio of Pedals/Back Wheel will drop to 0.

As for the back wheel speed, just count your prox switch on/offs for some time period to get the revolutions/time, and multiply by the circumferance of the back wheel to get speed in distance/time.

If your choice is the SLC 5/03 or the Mircologix 1000, then you will have to work around the problem of only having integer numbers, unlike a SLC 5/04, 5/05, or Micrologix 1100 with floating-point numbers. For this project, not having decimal points will be a major problem. You need to be able to make precision calculations on speed, time, and work done, and with only the limited integer numbers of 0 to 32767, you will find it very difficult to come up with meaningful calculations.

 

[blueyedpeter]

this is the last contact

Sorry to every one here is the data with out the woffel
The back wheel when over inflated the circumference is 2.008 m if under inflated tyres are used the circumference becomes 1995 mm

The back Wheel rotation max rpm 416.
The expected speed at 416 rpm would be 55Km /hr
that is slow as compared to a road racing bike because the gear ratios on a mountain bike are much lower for hill climbing .

The wheel rotation measured in Hz at 416 rpm would be 6.9 Hz
The back wheel rotates 24840 times in an hour approx.
Should i change the Tyre from a mountain bike Tyre to a c700 Tyre a road racing Tyre the new circumference would become 1987mm

I would either keep the Tyre average to about 1980mm or change the circumference to 1 meter and talk about speed in RPM and not translate it into Km/Hr
As i have found the common problem in cycling is accuracy in distance measurements brought about by carelessly inputting the wheel data into the little cycling computers .
Obviously comparing measured data to a GPS value as they never agree with each other .
So as i have stated before i am a pretty lousy programmer and have all ready wasted large amounts of time trying to guess my way to an acceptable answer.
I will try and find the other copy of code that was given to me and either modify it , but when it was tested the updated register n7 value was rather lethargic and i needed to calibrate it as it looked like it was measuring cubits

As this is the final note i wont ask again after this point as i have clearly offended some people here already .
So that's it gents if this information is not up to speed then quite frankly i don't have a clue as to what you wont me to tell you.

I thought it was a straight forward question , i was going to ask how i would write the code for measuring shaft speed of the keyway of an electric motor and put it that if the motor speed were to be displayed on a HMI wouldn't it have to be stored in a register and is that an N7 register , and later i would have to build the HMI and create a variable tag to look at that same register and display the speed value as necessary and keep the bike project out of it as it was far too convoluted , and as nun of the programming has been completed yet as i cant get past the speed value or reference .
Now Should not wont to answer i under stand and thanks again for all your efforts .
cheers and good health to you all and you families .

 

[uptown47]

If it's any consellation, your project makes perfect sense to me and your posts have been fine.

All you want is a bit of example code that will calculate speed of a wheel turning based on pulses coming from the wheel (same code for the pedals). Then you can work with and build on the code.

Unfortunately, I don't have a clue about AB or I would try and write something for you.

Good luck with it though, it sounds like a great project! ;-)

 

[Lancie1]

I thought it was a straight forward question , i was going to ask how i would write the code for measuring shaft speed of the keyway of an electric motor and put it that if the motor speed were to be displayed on a HMI wouldn't it have to be stored in a register and is that an N7 register , and later i would have to build the HMI and create a variable tag to look at that same register and display the speed value as necessary and keep the bike project out of it as it was far too convoluted , and as nun of the programming has been completed yet as i cant get past the speed value or reference.

So you just want an example of some RSLogix code that calculates the speed based on a prox switch input? Why didn't you say so! No problem! I will see what I can dig up, be right back.

 

[blueyedpeter]

thanks for your interest

yes i have all that i need but lack the experience , so they say that life is a never ending learning curve i don't trust my self to fix my own mistakes so i paid about $1000 Australian a couple years ago to buy a plc with all the extras and found this Allen Bradley with most of the input cards.
The only other card in needed was an analog input card and i found a card that had several inputs and several out puts and as not many people bib on it it was a steal the hard were was as much a finical battle as it was practical one so luckily it was a complete buy .The only dud was the old Eaton HMI it was a bit of a boat anchor they were unsupported

 

[OZEE]

Ya' know - this is a PERFECT example of proper engineering...

The most important, yet most difficult, FIRST step is to PROPERLY define your requirements. To define them in such a way that nobody can argue about what they are. DEFINE your system, how it works, how it starts/stops, how the operator interacts, how faults are detected/annunciated, etc., etc., etc.

ALWAYS do this FIRST, before you start trying to write code. When you start writing code first, you get mismanaged "spaghetti" code that will give problems.

Peter, I can find no place where you "have clearly offended some people here" Rather, it's an example of trying to figure out what you needed and going down a possibly wrong path because of assumptions.

So, is your question, as summarized by Lancie, how to calculate speed based on a prox input??

If so, let's forget about the PLC code portion. First, HOW would you do this on paper? DEFINE how you would get the speed based on a prox input, the calculations required, etc. THEN we'll worry about how to code it.

 

[Lancie1]

Here is an RSLogix Micrologix 1000 program for a basic speed calculation, with tire circumference = 2 meters.

 

[Lancie1]

The back wheel, when over inflated, the circumference is 2.008 m. If under inflated tyres are used, the circumference becomes 1995 mm (1.995 meters).

Peter,

I guess that you will have to keep your tire inflated so that it is exactly 2 meters. Otherwise there will be an error due to the fact that your choice of two PLCs have no floating-point numbers.

It is nice that it works out so that your tire is almost a whole number of meters, only needing a little tweaking of the air pressure to get it from 2.08 down to 2 meters. You are a lucky guy to have that happen. I don't remember ever having been so lucky in the real world of hard choices.

 

[Eric Nelson]

It is nice that it works out so that your tire is almost a whole number of meters, only needing a little tweaking of the air pressure to get it from 2.08 down to 2 meters.

Hey, I thought we already disproved the pressure vs. circumference issue?...

http://www.plctalk.net/qanda/showthread.php?t=71197



-Eric

 

[Lancie1]

Hey, I thought we already disproved the pressure vs. circumference issue?...

Eric, It could be. On the other hand, it could be that a bicycle tire is more like a balloon, where the circumference actually stretches a little as it is inflated. If the circumference is larger, then for each given 1 revolution, it would travel a farther distance if it was rolling on the ground.

But, due to the desired Speed Update time of 2 seconds:

. . .getting a speed reference stored into a register and getting it updated for accuracy about every 2 seconds is.

Then due to an unbelievable string of luck, two of the terms in the equation cancel out, so that Peter only needs to move a Counter Accumulated value to a memory storage location (say N7:0)!
Speed = (Revolutions X Circumference) / Time
Speed = (C5:0.ACC X 2 meters) / 2 seconds = C5:0.ACC meters/second
Can you believe it? Talk about luck! Is it possible for such conincidences in the real world? It is simply unbelievable that it works out so nicely, almost as if some unseen hand was guiding the project! :site:

 

[blueyedpeter]

Thanks guys

It should be mentioned that this bike never goes on the road as it will be up on a stand and is in a stationary or static condition . It will become a virtual push bike or a trainer. Also that Wheel circumferences are almost irrelevant as the tyre never comes in contact with the road and as such it will become a virtual speed reading and virtual by the fact that it is an assumed value not an actual value.

And also i should have mentioned that errors in this type of event are common place as there is a constant argument about will my cycling computer match my gps in my watch argument and the answer is undeniable no or never as there are different tyre manufactures and even when it comes down to it who cares if the power output is measured in calories or kilojoules there is no possible way of being totally accurate in either distance measurement or speed as there are as you pointed out variables like if the tyre is over inflated or not the actual road values of distance will always different .
On any other day it might only vary by a couple of fractions of a single percentage point but errors are always present. I went through this trouble some point one day while installing a paperless chart recorder the temperatures recorded were different from the original single chart recorders, which promptly drove everybody nuts. When looking at two slightly different values as these units were not installed by instrumentation experts , there would have been a litany of mistakes in the set up and installation but the company couldn’t or wouldn’t pay to get the right people to install and commission. So you get what you pay for. Any how gentlemen I will be off now and have a good day .cheers peter

 

[blueyedpeter]

gear ratios

The other reason that the gear ratios are important is it will effect the out put power the rider has to deliver. The front gear cluster has three different ring gears and the back cluster has nine ring gears , remembering that this is a mountain bike for hill climbing . So when you start to change gears smallest gear on the front and using the smallest gear on the back the turns ratio is around 1 to 2.24 and using the biggest gear on the front to the smallest gear on the back the turns ratio becomes about 1 to 4.75 in cycling terms this is fast for a mountain bike because the front gear cluster was replaced with a bigger set of gears. As this allowed speeding up the bike at the top end. Now this requires more leg power . Now even with the limitations of the plc I have , there is going to be some serious number crunching going on in the back ground .I will keep it brief as the rider climbs out of the saddle and rides on his toes he or she for that matter will in effect be carrying there own body weight in the air its much like climbing stairs but worse, when riding and sitting in the saddle you are pushing your weight through a vector , limited to just before you get up on your toes and out of the seat ,which is when the real work begins. Like I said to measure the out put in candy bars or a common Mc Burger the calories or kilojoules will need to be worked or at least assumed as this is more for humility reasons .Lets face it what you put in your mouth you need to pump out through your legs. Any how I am off to work soon catch you guys later and thanks again cheers peter