Engine Dynamometer Brake Control, DAQ & LabVIEW PID

[el bob]

That's a very interesting point about the flywheel working like a low-pass filter.  It looks like there will be an opportunity to see how much filtering it does when sampling time for the strain gage signal conditioner analog input comes into play.

Due to a mixup, it was not possible to run the dyno as planned so I was not able to experiment with the Boxcar filter changes I made to the TargetRPM VI or try Ziegler-Nichols tuning.  There should be an opportunity to take care of it this week.

I felt comfortable with the pseudocode form of the input averaging algorithm and could have easily written it in a textual programming language, but I was not sure how to write it in LabVIEW.  I searched on Google for some help and found an article that helped.

Here's a screenshot of the latest block diagram.

I did not get to test it, so I don't know if the new input code works.  Is there a better way to implement the algorithm discussed last week? 

Message Edited by el bob on 03-30-2009 03:02 PM

[CoastalMaineBird]

Is there a better way to implement the algorithm discussed last week? 

Yes. Although your method will work, the trouble is if you decide to change N to 4 or 53 or something, you have to do rewiring.  Not a good plan.

I explained this in a post on page 2, let's go over it again.

1.  Define a constant N, say 3 to start with.  If you want to change it, then change this one and only one place.
2. Outside the loop, use INITIALIZE ARRAY to create an array of N DBLs. (dimension size = N, type = DBL constant).
3. Outside the loop, have a constant I32 = 0. Label it BUFFER INDEX or something.
4. Wire the array and the buffer index to two sSHIFT REGISTERS on the loop edge.
5. For each reading inside the loop, use REPLACE ARRAY SUBSET to replace the element that BUFFER INDEX points to. Pass the updated array to hte shiift reg on the right.
6. Increment BUFFER INDEX (+1).
7. Compare BUFFER INDEX to N.  If INDEX >= N, send 0 to the BUFFER INDEX shift reg on the right, else send the new value to BUFFER INDEX on the right.
8. Use SUM ARRAY ELEMENTS to get the sum of all the buffer, AFTER replacing the new element.
9. Divide that sum by N.
10. Use that as your average.

That way, just changing the constant will change the buffer size, without any other code changes.

[walter-donovan]

"Force is measured from an Omega OM5 full bridge strain gage signal conditioner.  The OM5 is hooked up to a Revere load cell.  I don't know how the OM5 module computes its measurements and if it incorporates any kind of sample averaging system.  The torque output I have seen from it so far on an existing Innovate SSI-4 based data acquisition system looks fairly regular, but the SSI-4's LogWorks software may be sampling and averaging in the background."

When I read this part my reaction was that the load cell, sig conditioner averaging, etc were probably not the critical limit to sampling rate as the brake itself looks to have a high enough inertia  to filter out any intra-revolution data. It basically is a large flywheel and we all know a flywheel is typically added to an engine to filter out pulses.

When I read the sampling rate specs for the OM-5 my reaction changed to doubt of taking data fast enough. At a 600 RPM/s sweep, I think you will have a noticable lag between recorded and actual RPM skewing the per RPM data. This seems to be an existing behavior of commercial dynos anyway so how influential is this fact. Go Power and Superflow both give different torque readings for steady state and sweep tests respectively, upward sweep vs. downward sweep usually yield different results. You have to determine how accurate you need the data to be. I will say though that in the racing community where 1 or 2 or 3 HP makes a difference, no one would even think of comparing 2 sets of dyno numbers unless they were measured on the same dynomometer. This gives an idea of the validity of high precision data spewing forth from the commercial units.

[el bob]

Thank you for breaking the algorithm down into steps like that.  I'm not familiar with some of the LabVIEW commands so your outline with component names was a great help.  I sketched out what I think the VI looks like.  Here's the link.

09_04_01 TargetRPM VI Block Diagram Screenshot (Case Structure = True)

09_04_01 TargetRPM VI Block Diagram Screenshot (Case Structure = False)

09_04_01 TargetRPM VI Front Panel Screenshot

I started thinking about how the TargetRPM VI can be used to make the larger goal of a Power Sweep/Torque Map control VI.  At first I thought a new, blank VI would need to be created that would call TargetRPM as a sub-function, but then I had an idea to try and just manipulate the PID setpoint variable in TargetRPM.  I just wanted to hash out the idea, so I made a VI equivalent to notes on scrap paper showing just the part that would substitute for the current, static numeric control feeding the PID Setpoint variable in TargetRPM.

I wasn't sure how to keep track of loop execution time, but I saw a few timed loop functions that have timing feedback functionality.  I just put in a dummy constant 10101 to represent the concept of keeping track of summing elapsed time during a power sweep test.  The formula I tried to model in LabVIEW was the following.

Power Sweep Setpoint = SweepStartingRPM + (SweepElapsedTime/SweepTotalTime)*(SweepEndingRPM - SweepStartingRPM)

09_04_01 PowerSweep VI Block Diagram Screenshot (Case Structure = True)

09_04_01 PowerSweep VI Block Diagram Screenshot (Case Structure = False)

09_04_01 PowerSweep VI Front Panel Screenshot

There's an exceptionally large engine on the dyno right now.  It stands taller than I do (5ft 11in).  There's a decent chance I will be able to test the TargetRPM VI input averaging changes and try Ziegler Nichols PID tuning with it.  The first round of testing was done on a more common, medium size diesl engine around 6L's in displacement.  It would be nice if the same PID tuning parameters could be used for closed loop braking control for all of the different engines the dyno will see, but I am guessing that it will not working out this way.

Message Edited by el bob on 04-02-2009 08:24 AM

Message Edited by el bob on 04-02-2009 08:25 AM

[el bob]

---

walter-donovan wrote:

"Force is measured from an Omega OM5 full bridge strain gage signal conditioner.  The OM5 is hooked up to a Revere load cell.  I don't know how the OM5 module computes its measurements and if it incorporates any kind of sample averaging system.  The torque output I have seen from it so far on an existing Innovate SSI-4 based data acquisition system looks fairly regular, but the SSI-4's LogWorks software may be sampling and averaging in the background."

When I read this part my reaction was that the load cell, sig conditioner averaging, etc were probably not the critical limit to sampling rate as the brake itself looks to have a high enough inertia  to filter out any intra-revolution data. It basically is a large flywheel and we all know a flywheel is typically added to an engine to filter out pulses.

When I read the sampling rate specs for the OM-5 my reaction changed to doubt of taking data fast enough. At a 600 RPM/s sweep, I think you will have a noticable lag between recorded and actual RPM skewing the per RPM data. This seems to be an existing behavior of commercial dynos anyway so how influential is this fact. Go Power and Superflow both give different torque readings for steady state and sweep tests respectively, upward sweep vs. downward sweep usually yield different results. You have to determine how accurate you need the data to be. I will say though that in the racing community where 1 or 2 or 3 HP makes a difference, no one would even think of comparing 2 sets of dyno numbers unless they were measured on the same dynomometer. This gives an idea of the validity of high precision data spewing forth from the commercial units.

---

You make a lot of good points.  Short of switching to more capable strain gage signal conditioning hardware, I'm not sure how much can be done to improve the time reponse (I'm not sure what the right term here is) of the RPM signal capturing.  600RPM/s would be on the high side of desired acceleration rates.  Most of the medium size motors will probably rev through a 1,500RPM to 2,000RPM wide sweep.  I don't expect there will be much of a problem with stretching the sweep over five seconds, leaving 400RPM/s and 300RPM's acceleration rates.  The only part that may be tricky is handling resonance points where some of the diesels really don't like to operate.  The test cell operator just wants to make sure the engine doesn't spend too much time sitting in such an area of its rev range.  The details of the problem, if it turns out to be significant, will likely become more clear after the first couple of sweep tests.

I didn't know that about race teams and dyno comparisons.  I suspected it and understood the reasoning, but it's neat to hear it from someone in the know.  In the bolt-on sector of the performance community, dyno numbers can really stir the pot, especially when a car owner takes a trip over to a Dyno Dynamics chassis dyno after visiting a Dynojet chassis dyno.  The Dyno Dynamics piece has developed a reputation as "the hearbreaker."  It's nice to see there's a sense of humor about it. 🙂

Message Edited by el bob on 04-02-2009 08:45 AM

[el bob]

I accidentally left an extra space at the end of some of the URL's and so a few of the above links are not working.  Below are working versions.

09_04_01 TargetRPM VI Block Diagram Screenshot (Case Structure = True)

09_04_01 TargetRPM VI Block Diagram Screenshot (Case Structure = False)

09_04_01 TargetRPM VI Front Panel Screenshot

09_04_01 PowerSweep VI Block Diagram Screenshot (Case Structure = True)

09_04_01 PowerSweep VI Block Diagram Screenshot (Case Structure = False)

09_04_01 PowerSweep VI Front Panel Screenshot

[el bob]

There was an opportunity to run an engine on the dyno with the LabVIEW bits hooked up for a bit of PID parameter tuning.  I inteded to try Ziegler Nichols tuning, but the way I had the LabVIEW Front Panel displays set up prevented any on-the-spot tuning.  I added a few more data capture bits to the TargetRPM VI and aimed to gather enough data to perform tuning analysis after the dyno session.

Twenty or thirty logs were taken, but it took a few tries to get the WriteToFile modifications to work properly so a fair number of the early logs are incomplete.  Listed below are graphs of portions of the successful logged runs.

Test 16, Kp=2.0 Ti=0 Td=0

Test 17, Kp=3.0 Ti=0 Td=0

Test 19, Kp=4.0 Ti=0.002 Td=0

Test 20, Kp=4.0 Ti=0.004 Td=0

Test 21, Kp=4.0 Ti=0.006 Td=0

Test 22, Kp=4.0 Ti=0.008 Td=0

Test 24, Kp=4.0 Ti=0.002 Td=0.001

It looks like the parameters are getting closer to usable values.  At some point they will be "within range" and it will be time to see how the PID control responds to a sweep type test.  The VI Power Sweep scratchpad I posted last time was my first thoughts on how code might be put together to run a sweep type test.  The plan is to work on a more thought-out, fuller implementation.  If it's interesting to you guys, it would be great to hear your thoughts on this.

Have a good one,

Rob 

[bretzel_59]

Your project was very interesting, but every links are dead !

I'm working on the same project for gokart engine with a telma.

[Priyadarsini]

Hi Rob,

I too am working on a dynamometer project. I am currently working in the PID section. It would be very helpful if you could post the working links for the PID section.

Thanks,
Priyadarsini

[RevHead]

Hello , seems this post has been followed by numerious people with the same interest " Engine Dynamometer computer data acquisition system And/or Controller " converting old analog gauge system to a computer system,.whether the dynamometer is eddy current or water brake application Engine Dynamometer.

Just curious on how successful this project end result worked out ???As now I'm on a similar path as to converting my old analog gauge system water brake engine dynamometer  to a computer system.

Old post I had to revive , Any further updates ????

RevHead