Reading Quadrature Encoders

wilshire

I am working on a project in which I need to acquire rotation speed and direction for two quadrature encoders (36 pulses/rev). I figured that this would be a common application and I'd find tutorials on how to do it.... but I've searched through this forum and I'm still lost. I'm not a software or electrical guy and I've only had a small amount of programming experience. Can someone direct me to some useful materials? BTW, I'm using the BASIC Stamp 2 HW Board.

Post Edited (wilshire) : 3/26/2010 2:57:09 AM GMT

Franklin

You might find something here www.parallax.com/Store/Accessories/MotorServoControllers/tabid/160/ProductID/665/List/0/Default.aspx?SortField=ProductName,ProductName

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

MrBi11

this should help: http://abrobotics.tripod.com/Ebot/using_encoder.htm

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Smile ... It increases your face value!

Chris Savage

The BASIC Stamp Modules are too slow to read an encoder at any more than hand-turned speeds. However the SX (Currently EOL) and the Propeller can read them just fine. In fact, there is an object for the Propeller which reads up to 16 encoders at the same time and could easily handle the speeds and resolution you're trying to get.·

I will attach a simple quadrature encoder program for the BASIC Stamps, but you'll find it can't keep up at high speeds.· Take care.

P.S. - A & B go to P0 and P1.· these need to have a pull-up resistor (10K to V_DD) and COM needs to go to ground.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage

Parallax Engineering


Post Edited (Chris Savage (Parallax)) : 3/31/2010 2:40:08 PM GMT

erco

I'm reading two wheel encoders (one sensor per wheel, a quadrature encoder has two) at a decent clip without ever missing a pulse on my BS2E Retrobot. 36 PPR, probably ~80 RPM. Probably can go faster, too. A Homework Board is just as fast as a BS2E, so with tight code (and doing nothing else) you should be able to make two quad encoders keep up at 40 RPM or better at 36 PPR.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

RobotWorkshop

The July 2008 issue of SERVO magazine has an article I wrote about encoders and the problem of encoders with a resolution too high for the controller that is meant to read them. If you don't check them often enough you'll miss counts. The article had example code for an encoder processor that scaled the encoder value to something the controller could handle. It kept track of the intermediate counts so nothing would be lost. I believe you can still order the back issue from SERVO. If they are out of those they sell them on CD for each year.

Robert

Chris Savage

Erco,

Not sure how you're reading those at anywhere near those speeds...when I first tested rotary encoders on a BASIC Stamp using code similar to that posted above, I placed a Grayhill encoder in the circuit and turned the knob. Up and down the count went just fine. But as I did it faster (by hand) the count would jump and sometimes o backward, which is normal when pulses are missed. @80 RPM with 36ppr that would mean your BASIC Stamp would be counting 48 pulses per second! I just don't see that happening...now at 40RPM you're less than one rotation per second, so that is possible. Of course, to get the speeds I was getting I was using a BS2px. I don't recall the BS2 keeping up.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage

Parallax Engineering
·

erco

Chris:

I love a good challenge! I'll have to measure the actual RPM later, I am guestimating here at work. The encoders worked fine on the bench with motors at full speed (24V), then I slowed it down to 18V for better robot drive dynamics. Again, I'm not using quad encoders, just a tach sensor that counts pulses, but doesn't show direction.

Software attached that·synchronizes the wheels·as shown at http://www.youtube.com/watch?v=VzbKlwc4GWs
It's a very short software loop: the Stamp only looks at the two wheel sensors, counts transitions, compares left/right totals, and switches·two speed control relays. This looks like just below·60 RPM, and again, this is only using·18 volts.

I gotta give props to the Hamamatsu sensors I used, they do a great job reading the encoder disks, filtering·and signal conditioning. No false readings.

Of course the Stamp can only go so fast, and that will limit how many pulses per second can be read reliably. It might be fun to find out what that number is. I do like to push them Stamps as hard as I can...


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

erco

WOW, am I ever bad at guestimating RPM. My robot only runs at 34.2 RPM on 18 volts and 46.7 RPM on 24 volts. That's barely half of what I claimed above, Chris, so just for you I put on a 72 stripe encoder wheel instead of my usual 36 to make things interesting. Surprise, the BS2E keeps up just fine at 46.7 RPM. That's 56 pulses per second (PPS). I'm only watching one wheel right now, but I'm able to sample each black or white stripe many times between transitions, so I'm sure there's plenty of time to watch both wheels at that RPM.

That's good news all around, I had been putting off testing those 72-stripe encoder wheels and now I know they work fine, after some experimentation on the optical sensor location. Here are a few things I learned about the encoder sensors and their "view" of the encoder wheel tonight:

1) The stripes on a 72 wheel are obviously thinner by half compared to a 36 wheel. The radial stripes get wider further from the axle centerline. Moving the sensors radially outward from the axle gives them a wider stripe to read. They prefer a nice wide stripe.
2) The sensor's proximity to the wheel is critical for optimum performance and highest PPS count. It's an A/D converter, and the ratio of low/high, black/white needs to be darn close to 50%. I adjusted the sensor/disk gap to achieve this.

So even though I overestimated my RPM earlier, the numbers I measured tonight indicate that a BS2 (or BS2E) can keep up with two 36 PPR quad encoder pretty well. Certainly 30 RPM, probably 40 is achievable. Now I've been assuming that a 36 PPR quad encoder uses a 36-stripe encoder wheel. Is that correct, or is a quad encoder rated by the total pulses from both sensors (90 degrees out of phase) in which case this would only use a 16-stripe encoder wheel? If that's the case, then the BS2 situation becomes twice as good.

And no, I'm not April foolin'!

Edit: The disk shown in the Parallax position controller kit (which Franklin provided a link to previously)·answered my last question. Namely a 36 PPR quad encoder does use an 18-stripe encoder, so this should double the achieveable speed to 60 RPM or better.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Post Edited (erco) : 4/1/2010 7:04:27 AM GMT

stamptrol

Hi all,

Using an encoder to measure speed alone is quite a different exercise than using a quad encoder to track distance and/or direction. I'm with Chris as to the maximum realistic speed to expect.

The real test is to be able to zero the count, turn the encoder in one direction then back it up until the count goes back to zero. If you haven't missed counts, the shaft will be in the original position. When you go too fast, the evidence is very clear.

Cheers,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

Let's Go!

Is the bs2 problem the speed of each read or the speed of reading one after the other on the optical disc?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The smarter I get, the more I understand I don't know!

stamptrol

Measuring speed alone is simpler (and less time-intensive) because we do a sample with COUNT or PULSIN. Basically watch a pulse stream for some period of time and calculate the speed as a result of measuring the pulses in the sample period. Then ignore the pulses while the processor does something else and then goes back to check the speed again.

Using quadrature encoding you are essentially watching the relationship between two pulse streams in real time. Each and every pulse is important in calculating how far the encoder shaft has turned and which direction its going. That requires dedicating more processor time to the task and therefore places a limit of counts per second that the processor can accurately keep up with.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

erco

Tom & Chris:

Very interesting thread, you guys have my encoder curiousity piqued. I know you're both smarter than me and are drawing off of real quad encoder experience, of which I have none. But based on what I've learned from my tach encoder experience, I don't feel that the Stamp should be as limited as you describe. I set out today to see how fast the Stamp could read my wheel spinning faster than normal. Granted, this is still one encoder counting stripes, but all I'm interested in is pulses per second for now.

(And BTW, I'm not out to prove anybody right or wrong here, I just enjoying learning and pushing the limits of a BS2. I'm an ME, and I work with a lot of EEs at work. I take a lot of ribbing for using Stamps in my prelim projects, but they have never let me down, while on occasion the EEs stumble with their EMC micros)

I bench tested one of Retrobot's motors at 48 volts (all the gel cells I could find!) instead of my usual 18 volts, so those motor control relays took a beating! One popped, ah well. I consistently got 10 revolutions in 6.0 seconds, which equates to 100 RPM. Using that same 72-stripe encoder wheel, I never missed a stripe. My program starts the motor, runs it for 720 encoder transitions (10 full revolutions), stops the wheel, pauses several seconds, then repeats. Each time in a dozen consecutive runs, the wheel always stops in exactly the same position, that's how I know it's not missing any pulses. 720 transitions in 6 seconds is 120 transitions per second. That's the same as 120 pulses per second, isn't it? BTW, it may operate even faster; that's not an upper limit in Stamp performance yet AFAIK, just the max RPM I could generate today.

Now I'm interested in making a quadrature encoder and testing per Tom's criteria listed above...

@Chris: I like the tight little quadrature encoder program you attached previously. It looks like it was edited down from a larger program that used two quad encoders and a one-wire output connection, so this may be part of your original BS2px code. Looks like it should scream along pretty well except for that DEBUG statement, which slows everything down drastically. Without that, I think even a vanilla BS2 could keep up fairly well. Eight LEDs as binary outputs has got to be faster than a DEBUG statement. That's my plan of attack for now, whenever I can get around to it. Not that I have screaming babies to feed or diapers to change here... [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Chris Savage

erco,

Sorry, I hadn't gotten back to this thread in a bit (been busy), but what I wanted to say after re-reading the above was that comparing the tach wheels to quadrature encoders is apples to oranges. The BASIC Stamp has an instruction optimized for reading a tech type input. Once executed this instruction is really running an assembly code routine within the stamp. The COUNT instruction can read puses at up to 120,000 Hz in such a sitation and could easily be used in a tachometer for high speed devices (See Ken Gracey's Milling Machine RPM Display). But with a quadrature encoder you have to read and compare the bits with the previous bits every time there is a change. So now you have this tight loop of instructions where your main limitation on the BASIC Stamp is the EEPROM read/execution time. Because of that a quadrature encoder could be read at nowhere near the speed a tech signal could.

The BASIC Stamps are not slow in the technical sense, and can do a lot more than most people give them credit for. I know, I have created commercial applications based on them. But I also know the limitations. Definitely try what Tom suggested. And yes, the DEBUG statement slows things down. But you need some way to track the count, so you could always modify the code to display the value some other way. And yes, that code was stripped from my Solder Pot Contoller application...forgot the one wire assignment, did I? [noparse];)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage

Parallax Engineering
·

erco

My, you're on the job late, Chris! Oh, don't worry, I wouldn't stoop to using the COUNT command; that would be cheating! Besides, I don't think that would allow the necessary control. BTW, I say "tach sensor", that's because according to Wikipedia, "Rotary sensors with a single output are not encoders and cannot sense direction, but can sense RPM. They are thus called tachometer sensors." I don't really care about RPM in my applications, butg mainly cumulative accrued distances for robot navigation, which is not unlike keeping tabs on a twirling knob, as this thread suggests.

My code definitely looks for discrete input states on Stamp pins, good to at least 120 transitions per second so far. And of course a quad encoder with two sensors will run at one-third this effective speed with all the IF checks. My code isn't the greatest, I'm always looking to learn better tricks. That's why I particularly liked your single code line:

counter = counter - 1 + (2 * (newBits.BIT0 ^ oldBits.BIT1))

It's very elegant and compact. I assume it executes faster than a series of IF checks and the appropriate addition/subtraction.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

stamptrol

· Hi erco and all,

·· Testing is good!

·· I've attached the encoder code I've used. You'll see it is very similar to Chris' and I adapted it·from a 1991 text by J.D. Nicoud.

··

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com

erco

Tom: Thanks for the assist; you didn't leave me any software to write! Your code is perfect, it has 8 LEDs as output indicators and even includes a sweet little "clockwise" LED indicator.

As I said, you guys have been doing this quad stuff a lot longer than me. Thanks for bearing with me as I learn and try to close the knowledge gap a bit. I've been staring at that one key line of brilliant minimalism:

direct=new.BIT1 ^ old.BIT0 ' XOR left bit of new with right bit of old to get direction

(which Chris' program also uses, slightly differently) and would not have thought of doing that. You, Chris and this Nicoud guy have "got it goin' on".

Eric

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Chris Savage

Learning is what these forums are all about. I guess we all just needed to get on the same page as far as what type(s) of inputs we were referring to. And, while I would like to take credit for the code I posted, I can only take credit for compacting it by one line. THe original code I was reading was written for the PIC by Jeff Martin when he first started working at Parallax many years ago. Compacting the code by merging two lines though doesn't really make it run much faster as all the individual calculations still have to be carried out. I think I saved one assignment that was done on the second line.

I hadn't realized you weren't using COUNT. It is the most efficient instruction for measuring high-speed pulses, but not practical if you can't afford to wait for a period of time to elapse. And while I will continue to use BASIC Stamps for many years in my projects that will run from one, it is for reasons like these that I am migrating toward the Propeller Chip for specialized high-speed counting and encoder reading.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage

Parallax Engineering
·

Tracy Allen

I tested the following snippet to see how fast it runs through the loop. That is the crux of the matter. It has to execute at least once without fail for every stripe.

' {$STAMP BS2e}
' {$PBASIC 2.5}
' read quadrature encoder, [u][url=http://www.emesystems.com/BS2fsm.htm#twobit]www.emesystems.com/BS2fsm.htm#twobit[/url][/u]
old VAR NIB
new VAR NIB
x VAR WORD
cnt VAR WORD
goal VAR WORD

move_to_goal:
old = INC
goal = 1000
HIGH 1  ' start travel of motor on pin p1
DO     '   This is the main loop!
  new = INC & %11
  cnt = (old ^ new MAX 1) * (old.BIT0 ^ new.BIT1 << 1 - 1) + cnt  ' edit: order of operations cnt comes last
  old = new
  TOGGLE 0   ' for 'scoping
  LOOP UNTIL cnt=goal   ' end of travel
LOW 1  ' stop travel of motor on pin p1
STOP

Execution time, 2.53 milliseconds for each time around the loop (395 times per second), including the exit condition. This on a BS2e, which has the same speed as a vanilla BS2.

That is well within Erco's claims, where 30 RPM on a 72 stripe wheel equals 36 stripes per second or a very comfortable 27.8 milliseconds per stripe. On the other hand, with a 256 stripe encoder at 60 RPM=1 revolution per second, it becomes borderline, 3.9 milliseconds per stripe, and it is easy to move it faster than that. A DEBUG command inside the loop stretches the execution time out to more that 8 milliseconds with a DEC3 formatter.

This program differs from the one that Chris posted above by replacing the IF THEN construct with a computation

(old ^ new MAX 1)   ' equals one iff new<>old, which allows count to increment

Doing it by computation makes the execution time the same whether or not the bits change (within about 20 microseconds).

I read out the times from toggling pin p0, on the expanded scale of a LeCroy 9354 'scope. Using << 1 instead of *2 in the math shaves about 35 microseconds off of the time.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Post Edited (Tracy Allen) : 4/4/2010 1:44:18 AM GMT

erco

Tracy: Thanks for jumping in! Wow, I couldn't PAY FOR better tech data than you provided here. Thank you so much for taking the time to make those very precise measurements. We all know the BS2 has its limits, but I'm sure the little fella appreciates all the support here. I'll get started on building a demo encoder today. Will advise (and probably Youtube) my findings.

Thanks again and Happy Easter to all!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

erco

Testing this right now. Running at 95 RPM now and the BS2 didn't miss a beat. Encoder wheel is 16 stripes, yielding 32 PPR with a quad encoder. We had been talking about 36 PPR, but since I'm using 8 LEDs to display the binary count, it seemed more natural to go with a binary split on the wheel so that each full revolution of the wheel should end up displaying a nice even binary number on the LEDs.

Won't stop until I crack 100 RPM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

erco

Amazingly, the quad encoder tests rock solid at 212 RPM, 32 PPR, 113 pulses/sec. Not missing a single pulse. Can probably go faster. That BS2 is a champ!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

PJAllen

I appreciate your spirit of experimentation, a sense of life·which is·sorely lacking around here.· You're getting in there and pushing the envelope, which is the way things ought to be.

erco

Thanks, PJ. AFA "pushing the envelope", I like to torture-test myself running marathons & doing long bike rides. Today, it's the BS2's turn in the Torture Chamber.

I can't believe I'm up to 615 RPM and the BS2 hasn't flinched. Never missed a beat. 327 pulses/sec. Rock solid encoder counting.

But I AM smelling ozone coming out of my poor Solarbotics gearmotor running at 18V! I better video this thing before the motor dies.

327 pulses/sec is approaching Tracy Allen's loop count of 395 times per second. I'm quite satisfied with these results. That motor is hauling Smile.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

erco

Judging from the lack of replies to this post, I'm the only one who gives a flying fandango about the BS2's ability to read a quad encoder at speed. That might stop an ordinary guy from shamefully resurrecting his related thread. But you know me better. I'm fully prepared to bore the pants off of my fellow forumites until somebody says, "Wow, that's faster than I expected." Is that·so much·to ask?·

Perhaps people think I've been blowing smoke with my previous claims, so I now have video proof. (Re: blowing smoke, we'll get to that in a minute.) See my test run at http://www.youtube.com/watch?v=MFqNmntFEnE·which used 18 volts and achieved perfect encoder tracking results at 615 RPM, or 327 pulses per second. I was quite pleased with those numbers, the same numbers as·in my last·post.· But still no one noticed. No one·cared.

Hellbent on self-destruction and retribution, I made the jump to Hyperspeed: 24 volts. They would HAVE to notice me now! Only once, briefly had my Solarbotics motor tasted this power, and·wisp of·smoke was released. I knew that with great power came great responsibilty and in all probability, very fleeting fame & fortune. I videoed the one-time beauty and tragedy of a Vigor (Solarbotics) 3-volt gearmotor living a lifetime of revolutions in 5 seconds. But in those seconds, the BS2 once again tracked the encoder wheel perfectly and never missed a pulse at 738 RPM, and 394 pulses per second: http://www.youtube.com/watch?v=VmNc_V5jdPE·The fireworks show inside the white·motor end bell is quite dramatic.

By sheer, staggerring coincidence, this number almost perfectly matches Tracy Allen's calculated maximum encoder count of 395 PPM from his previous post. DON'T MESS WITH TRACY ALLEN!··I'm quite satisfied that these two numbers, independently derived, are sufficient to indicate·the reasonable maximum·perfromance obtainable from a BS2 in this application.

Thanks to Tracy, Chris & Tom for sharing their versions of code, which shared that very fast-executing XOR routine which made these results possible.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Post Edited (erco) : 4/18/2010 5:01:22 AM GMT

PJAllen

No one noticed?· What am I, chicken liver?· What do you want, a cheering section?· [noparse][[/noparse]"Jump, erco. Jump!"]

Well, at least no jackadze has come along and stapled spam into this epic account of your exploits.· I appreciate the videos, too, whether they get picked up by "Maximum Exposure" or not.

(Funny thing, the OP has been totally nowheresville since beginning this subject.)

hover1

I for, one, am impressed! I echo PJ's comments about your spirit of experimentation. I don't know where you find the time with the twins!

Observing moment of silence for the brave motor.

Jim

stamptrol

erco,

Congrats on your progress! We haven't been ignoring you, just quietly waiting for the next report.

Too bad you toasted the motor, but ya gotta break a few eggs to make an omelet.

Are you going to post the final version of the code?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

sam_sam_sam

I have look at this post as well that was·something with that motor just going up in flames like that it did run for a few seconds then a ball of fire and a little bit of smoke POOR motor just could not take it no more·with all that testing

·····························································

·Please· ....·>>>>>·Lets · Observing moment of silence for the brave motor· all in the name of ||||



·To·see how far we can push a Basic Stamp and a little motor



Keep up the good work·····


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·Now wanting to learn Spin· Thanks for any··that you may have and all of your time finding them

·
·
·
·
Sam

Tracy Allen

Alas poor motor, indeed! I feel responsible, but not yet vindicated. The theory for the limit of speed is not validated until you hit the point where it first starts to miss counts!! Oh no, not another pyrotechnic motor. It would be gentler to substitute an encoder wheel with more stripes. Did you say you had printed the encoder wheel yourself? It is really interesting to see your experimental setup and explanation.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

erco

@Tracy: Just when I thought I was out, you pull me back in... You're right, of course. I've come this far, and I have the rig, so I really should see what happens beyond 400 PPS. (Maybe part of me doesn't want to acknowledge the BS2's limitations!) I couldn't believe that my PPS count coincidentally·matched your number; I·kept rechecking, but sometimes truth is stranger than fiction!·I'll retrofit a faster motor and test, that (yes, homemade, MS paint) 16-segment wheel made it easy to verify the binary count accuracy. But it will have to wait a while. We're getting ready for a fly/drive vacation adventure with our 6-month old twins, and there is much to do... Thanks for your help and encouragement, will report back when I can.·I certainly appreciate that you have taken interest in my primitive tests. I realize that you did all this and more, over 10 years ago. You are a Guru!

@PJ: You ain't no chicken liver! You're a big dog here in the forum and certainly one of my Parallax techno-heroes. I thank you and Tracy for all the encouraging things you said. I was·intentionally overdramatic in my post. I don't want VIRAND getting all the attention in the forum!

@Tom: Sure, I'll·my code·here; it's Chris' code, just modified for the pins I used. It's also a two-part program: at power-up, if both encoders see black, it enters the "display encoder sensor output" mode. Otherwise, it counts in binary.

@Sam, Jim, Tracy·& Tom: Surprisingly, the poor motor still works pretty well! It actually sounds good, but clearly something·unhealthy happened on·its·final run. I yanked the power after I "saw the light", so it lived to see another day.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."