[BUG] Leak Test Calibration data - out of range

[DeeEmm]

Software Version

• RELEASE (e.g. V.2.0-RC.7)

Describe the bug Calibration value for leak test incorrect / out of range

Reported by @black-top

Review leak test calibration code

[DeeEmm]

Looks like the calibration data is simply not being saved to or read from the calibration file.

The -1000 value is just an arbitrary value used in the initialisation...

` /***

• Calibration Data ***/ struct CalibrationData { double leak_cal_press_val = 1000.0;
  double leak_cal_vac_val = -1000.0;
  double leak_cal_val = 0.0;
  double flow_offset = 0.0;
  }; `

The reason that the calibration data is not being read or written is that the code is commented out in Calibration::parseCalibrationData

I've uncommented it and tweaked a couple of things.

I will upload to master.

[DeeEmm]

okay. uploaded to master.

@black-top can you test and see if this fixes the issue

[black-top]

Thank you for your quick response. Now the "measured leak test value" always stays -1 instead of -1000 as before.

[DeeEmm]

Haha. okay. So I'm guessing it's either not writing to or reading from the calibration file.

I uncommented the code that was already there, but there is obviously a reason that it was commented out

I'll try and take a look tonight.

[DeeEmm]

Just trying to get the flow calibration discussion back on topic so moving the discussion from the flow calibration thread to here

https://github.com/DeeEmm/DIY-Flow-Bench/issues/179

@stefan63

I guess and think that the leak check could be done at a far lower pressure than 28" no reasont to press the system to it maximum. After all its just a way to test for leaks so not super critical but to be able to leak check we need ti be able to create a stable vacuum/pressure and be able to compare it from end to end, if a contant regulation have to be done it will indicate a leak. I also feel that a modulated blead valve is more prcice than a motor speed regulation ever can be, no matter if its a VFD or other type of PID regulated speed controller.

Yes, these are my thoughts too, but I accept that people will want to test at higher depressions. Superflow test at 25", so essentially this is the defacto standard, whether we agree with it or not.

The big problem with trying to leak test a MAF based system is that the system is one single plenum, whereas on a depression style bench the system is split into two plenums by the orifice. So you regulate your test depression by adjusting the depression under the orifice and then measure the depression that you get above the orifice. Any differential and you've got a leak.

With the MAF style setup you cannot do this. All we really have available to us is mass flow. If we register flow, then there is a leak somewhere. In this regards we are not comparing apples with apples by adopting the 25" standard of the Superflow bench.

We can however do a simple test to determine how the reference depression impacts the ability to leak test. We simply introduce a controlled leak of say between 1-3cfm and then map the flow values over a depression range, starting off at a very low reference depression and gradually increasing it. Maybe in 1" increments.

We can also try to predict this...

Flow at the new pressure drop = (SQRT (new pressure drop/old pressure drop)) x CFM at the old pressure drop

Lets start at an arbitrary test with a leak of 1 cfm and a depression of 4" which is about what you can expect out of a shop vac.

As you can see the difference between testing at 4" and testing at 28" is about 1.6 cfm.

If we compare the difference between 10" and 28" it drops down to less than 0.5 cfm.

I think that this shows that massively increasing the test depression for the leak test does not increase the flow characteristics to the point of it being a benefit. This is different for a differential style bench where increasing the depression increases the differential.

NOTE: edited as my initial excel screen shot was truncated

[DeeEmm]

Hi Guys. I've invited @danielerpl into this discussion from FB. Daniele is running a differential (orifice) style bench. @black-top & @stefan63 I think it is a good opportunity for all of us to get our heads together and work out a solution that works for all bench styles / applications

This is one of the few remaining issues that needs to be resolved for the V2 release. It would be good to get it solved. Obviously my first iteration missed the mark by some distance lol.

So far I think that it is clear that a solution for a MAF based system will not be appropriate for a differential based system and that even between different benches, things like test depressions will differ a lot.

The most basic solution is that the leak test is carried out manually and the resultant CFM figure is manually saved as an offset under the configuration tab > Calibration Data settings. This allows each end user to carry out the leak test that is most appropriate for their system.

~I think that there is a use case for people wanting to run BOTH MAF and Differential systems within the same bench, especially in a retrofit. So we need to consider how offsets work in this situation. Obviously we do not want to double up on the values but it does depend on bench design. Do we therefore need seperate offsets~ << I think this should be considered but parked for future development if the use case arises. I would assume that most designs would place the MAF in series with the differential system,

I think a good first step is to change the disabled fields for the configuration tab > Calibration Data settings, ~add pDiff offset~(I think cfm is better for differential flow) and allow the fields to be manually updated. This will at least allow people to perform a manual leak test of their own devising.

Then we can try to figure out how to automate the leak test calibration and leak test validation...

Leak test calibration - initial leak test setup - Ideal scenario where test surface is directly blocked with no leak to give baseline leak test reading.

Leak test validation - subsequent tests carried out each time a job is set up to validate the setup - inlet to test piece is blocked to test heads for leaks i.e. loose plug / leaking valves / cracked head / etc

Thoughts...?

[DeeEmm]

I've added the ability to manually update the calibration values.

This works along side the existing flow calibration function

[black-top]

I was thinking about a solution to fit all, but there are too many differences in systems. I think the simplest and best solution right now is just the ability to manually update the calibration values. So the calibration will be the same for all designs, but the calibration process can be type-specific. The procedure can be updated easily in the wiki and without any code changes. At the end of the day, all types of flow benches need leak value in CFM. Unless someone has a better idea to discuss and test.

I think more data for data logging will be more beneficial at this stage of code validation because it is a great opportunity to compare data with different types of flow benches, and more data will allow us to see what can cause the differences in readings, but this needs a separate topic.

[KirikauKiwi]

Thinking thorough the process, the flow bench firstly need to be constructed and tested for leaks etc in the cabinet, piping etc. Once the system is deemed air tight we are then only concerned with a leak between the cylinder head and the measuring devices.

Doing a closed system test, i.e. valves shut on the head, could be difficult as if a perfect seal is achieved (ideally what we want, i.e zero leakage) there will be zero air flow which will most likely cause stalling/surging in the vacuum pumps.

I think a known test orifice would have to be introduced/designed in to the system that can be easily accessed and opened during the leakage test, a leakage test port as such, e.g. in the case using a CD at 10" with a flow 14.4CFM. If the system is perfectly sealed you would have 14.4CFM at a 10" depression with the test port open, if there was a leak in the system you would expect a greater flow number than 14.4CFM and the difference between the actual flow and the expected flow would be the leakage offset.

Testing for the leak visually is important too and should checked, with either the likes of an incense stick/joss stick and looking for the smoke being sucked in or you could use the pitot sensor with a tube attached and use it as a sniffer inside the ports and around the flow bench to cylinder interface as it would pick up the change in pressure at the leak location. So it could be useful when in leakage test mode, the bench could have some sort of gauge on screen for the pitot sensor sniffer.

[DeeEmm]

Using the pitot to locate leaks is an interesting idea. There are plans on the roadmap to add a graphical / manometer style display to the GUI for the pressure and pitot gauges - just an analog representation of the value. So using it for leak testing as you describe is a possibility. But that's a down the track enhancement. (V3+)

The orifice idea is used commonly from what I have read and has been discussed previously. I think that this could work equally for the MAF and differential benches if closing the inlet off completely does not work for a particular bench.

After pondering over this today, I think that the method of the test is largely unimportant, as long as the same method that is used to set the baseline is then later used to do the comparison tests. Whether that is using an orifice, or a fixed plate, and whatever the reference depression used. This can be up to the end user to determine and can be driven by both bench type and capability as well as personal preference. We can outline a generic test in the WIKI as a point of reference and mention both fixed pates and small orifices as well as high / low reference depressions. But ultimately in all cases we are simply storing a CFM offset.

The leak test calibration is therefore simply the same as the flow calibration. The flow value is saved as an offset and then applied to all subsequent measurements. Once it is set it becomes the new baseline. The end user can use the 'calibrate leak test' button to store the value automatically or manually type the value into the configuration page and save it,

I think that there may also be some value in having two leak test calibration values. One for the bench itself. i.e. a fixed offset that addresses leaks and disparities found in the system when the test surface is blocked off. And a second value for leaks detected in the job when the test piece inlet is blocked off. This translates for both MAF and Differential style benches.

The reason for this is that the first value will theoretically not change, whereas the second value will potentially change from job to job.

Ideally you want the ability to block off the test surface and run a leak test on the bench itself at any time as part of fault diagnosis. So you never want to overwrite that initial baseline value for the bench. Otherwise you remove the possibility of being able to undertake that test. Baseline data is very important for condition monitoring and fault diagnosis.

I read a story of a guy that managed to detect one of his vac motors slowly getting loose over a period of time because he was seeing a drift away from his baseline leak test values.

You also want the ability to store a temporary offset for each job. For example you're working on a head that has a crack in it that's going to get welded up later on or has a dodgy sealing surface but will be getting a skim. So you can zero out the leakage from the crack / scratch, do your flow / port work / seat job / whatever and still generate a valid data set that isn't skewed by the crack / scratch leak.

To make the stored leak calibration data useful. The leak test validation just needs a way to compare the current test against the baseline.

Originally I was thinking of a go / no-go style of indication, but now I'm thinking that adding another tile that displays the difference between the current value and the leak test baseline value in CFM would be of more value. There's no pass / fail. The end users just decides if it is good enough by looking at the difference. Then if they want they can manually tweak the value, or hit the leak-cal button to update it and bring the differential back down to zero.

So...

• Baseline Offset (A)
• Leak Cal val (B)

Functionality...

• Both values can be manually updated via the existing configuration page.
• Hitting the leak-cal button saves the current flow value to leak Cal Val (B) only!
• The Baseline Offset (A) value is only manually updated. This will prevent it from getting accidentally overwritten (When you record the initial baseline measurement, you can save to B and manually transfer it to A)

So Value A is essentially permanent, whereas B is easy to set / change from job to job

Resultant maths...

ACFM = RawCFM + FlowCal offset + Baseline Offset (A) + Leak Cal Offset (B)

The end user can use all or none of these. They can also manually enter in any value and for any reason into the baseline offset field. It gives the system flexibility and the end user the opportunity to use the bench on ways that we may not have considered.

[black-top]

I agree, that will be the most universal solution. Just small detail, the corrections probably division from raw flow, not addition.

ACFM = RawCFM - ( FlowCal offset + Baseline Offset (A) + Leak Cal Offset (B))

And for the leak procedure itself, the pump surging probably can be fixed with a simple manual valve near the pump, to create a controlled leak, to stabilize pump running and depression, so all air will flow from the "controlled leak valve" and only leaks before MAF will be registered ass flow if any leak will be induced to the system.

[DeeEmm]

I think that one we start to look at closed loop motor / bleed valve control this issue will not be so much of a problem

[danielerpl]

@DeeEmm thanks for adding me in this discussion. Now I got it..... I was testing the bench with your step by step procedure explained, but was not working the function for the leak test. I tried also the calibration and apparently it's working fine at the moment. I am not sure if the value it's correct but the result value it's. pretty closed to the expected, described on the PTS orifices I am using. When you need some test let me know!!

[DeeEmm]

OK so code updated to reflect methodology discussed above. It is worth noting that there is an allowance for reverse flow, but I am unable to test this on my setup at present.

Both the flow cal and leak cal buttons work - both will save the relevant flow value to to the appropriate settings.

Maths for flow calibration and leak calibration values as follows...

sensorVal.FlowCFM = _calculations.convertFlow(sensorVal.FlowKGH) + calVal.flow_offset - calVal.leak_cal_baseline - calVal.leak_cal_offset;

So as you can see you can use both the baseline and leak cal values independently.

There is no longer any kind of calibration test. The code for the automatic test along with the settings has been removed. If you want to validate the leak test you need to compare the numbers manually.

I will however add in the additional pane to show the differential between current flow value and leak test value.

[black-top]

If I understand correctly, the total corrections value should be subtracted from the flow number ? Because any leak will give additional flow, but If in some case orifice will flow less than should, I think negative number should be written in calibration. So I think it should be like this:

sensorVal.FlowCFM = _calculations.convertFlow(sensorVal.FlowKGH) - ( calVal.flow_offset + calVal.leak_cal_baseline + calVal.leak_cal_offset);

[KirikauKiwi]

Another very useful tweak!!!

So...

Baseline Offset (A) Leak Cal val (B)

I would think of them as Reference Calibration & Trim offset respectively.

I can see it being very useful for the reasons already mention along with if you were trying to verify a cylinder head that has been worked on already and is claimed for example to flow X? CFM @ 28" and 500 thou lift and upon running it up on your DIYFB it flow something different. You could then use the offset to make it match and then verify the cylinder head at different lifts to see if your data matches their data, I guess allowing for the variation between their bench and yours!!! or it might possibly come in handy as a BS detector.

[DeeEmm]

Funnily enough I'm actually adding an additional 'user' defined temporary offset value. Call it option (C).

It can be any flow target you want. The target CFM of a head, or a manifold or maybe an object that you have to test a gazillion of, or like you say just an offset so that your bench can match someone else's baseline. I'm sure there are a bunch of other interesting ways to use it. That way we don't need to fudge with the calibration values.

[DeeEmm]

I would think of them as Reference Calibration & Trim offset respectively.

The terminology of these things is definitely something that is worth considering.

This is where I am at with the additional tile for viewing the flow differentials...

https://github.com/user-attachments/assets/3488b180-16fb-4792-9904-9e9144ade54a

I've had to reduce the click target to the tile title to allow me to add an additional target to cycle through the flow target types...

It cycles through Baseline > Baseline+Leak > User and back again

I did this to avoid having additional buttons on the GUI and risk things getting too clunky and cluttered.

[DeeEmm]

OK. Got the user differential flow target working...

https://github.com/user-attachments/assets/bdb6debc-a847-46af-8d4c-952a218498a1

The value is saved with in the calibration file and so will persist across power cycles.

As mentioned previously and elsewhere , the UI still needs a way to save the current state so that it retains the previous user view. I have some ideas on this that does not involve cookies, but that is still a way down the list.

I'll finish up testing and push the changes to master so you you guys can have a play.

If everyone is happy with the leak test and flow calibration stuff I'm keen to get it packaged up as the RC8 release

[DeeEmm]

ok. just to clarify...

we create the raw cfm value from the mass flow...

          sensorVal.FlowKGH = _sensors.getMafFlow();
          sensorVal.FlowCFMraw = _calculations.convertFlow(sensorVal.FlowKGH);

we then apply the leak and flow offsets...

        // Apply Flow calibration and leak offsets
        sensorVal.FlowCFM = sensorVal.FlowCFMraw  - calVal.leak_cal_baseline - calVal.leak_cal_offset  - calVal.flow_offset;

This gives us the main flow value that is displayed in the GUI

The flow differential targets are created like this...

        case USERTARGET:
          sensorVal.FDiff = sensorVal.FlowCFM - calVal.user_offset;

        case BASELINE:
          sensorVal.FDiff = sensorVal.FlowCFMraw - calVal.flow_offset - calVal.leak_cal_baseline;

        case BASELINE_LEAK :
          sensorVal.FDiff = sensorVal.FlowCFMraw - calVal.flow_offset - calVal.leak_cal_baseline - calVal.leak_cal_offset;

Note that the baseline differentials are based on the raw flow value. This avoids applying the offset twice.

So for example if we want to do a leak test, we set the bench up in the same way that we originally undertook the leak calibration (for example blocked off with a plate on the test surface). We can then select the 'Baseline' Flow differential. The resultant value should read zero.

This assumes / requires a few things...

• For initial calibration all offsets are zeroed
• First thing to be calibrated is leak test of bench with seal (or orifice) placed at test surface. This the baseline value
• Next we perform the flow calibration using the test orifice

Later, when we want to calibrate a job for leaks...

• job is placed on test surface
• valves are closed + plugs installed
• inlet ports is sealed with plate (or small orifice)
• This is the leak calibration value (or trim offset as KirikauKiwi describes it)

Note this value needs to be zeroed down for each job as it will change from job-to-job.

This is the basic functionality and flow. Agree that terminology definitely needs to be revised to avoid creating confusion / ambiguity. Would be good to align with language used by other manufacturers.

There is a caveat with this and one that I've gone through a few iterations of code and procedure with.

It is possible to flow test and leak test in any order.

sensorVal.FlowCFM = sensorVal.FlowCFMraw  - calVal.leak_cal_baseline - calVal.leak_cal_offset  - calVal.flow_offset;

Note we do not differentiate between the flow calibration value or the leak calibration value. The are all applied at the same time.

This means that if we first leak test. Then when we do the flow test, the value we store already has the leak test offset applied.

Conversely, if we do the flow test first, and then the leak test, the resultant value will be incorrect.

There is no real way to pick this up without further complicating the code. So at this point in time, it is reliant on people following the correct procedure to calibrate. But it is possible to calibrate in the wrong order and create an error of the magnitude of the leak test.

[DeeEmm]

Okay. All changes now pushed to master.

Please test / review / critique and get back to me

[black-top]

I did some quick testing, and it looks like everything is working as intended.

[black-top]

I did some more testing, everything is working as intended, I don't see any new issues. BTW, I see now reverse flow when the pump is surging, so it looks like this code is working too.

[danielerpl]

It is possible to have a step by step procedure to make the leak test and calibration test? We can put it in the wiki section. Should be very helpful bevause a wrong leak test or calibration, can make a wrong result value

[DeeEmm]

Hi Daniel.

Yes we do already have the flow and leak calibration procedures in the WIKI, however I do need to update them as we have added the additional baseline values to the code.

https://github.com/DeeEmm/DIY-Flow-Bench/wiki/Calibration

I update it shortly

[danielerpl]

Perfect! I got it ✌🏼 Sorry if i didn’t see it before, is my bad 😉 I was looking for it but i didn’t found it.

have you tried the functionality to update the index.html? i was investigating on it yesterday and the first time you upload the file it works welle, but when you use the delete or file’s upload functionality nothing is working. Also in the log nothing is displayed. It’s like the “data” info from the html form it’s not valorized as expected I continue to make some test to understand where is the problem

[DeeEmm]

All good, just finished updating it.

Yes the file upload works perfectly here. Are you using the current versions for both the main code and index.html (in 'data' folder)?

https://github.com/user-attachments/assets/7c67dc32-a21c-4488-8a79-191f7f1ad592

If you cannot upload the index.html via the browser then you will need to upload it via VScode

[DeeEmm]

It’s like the “data” info from the html form it’s not valorized as expected

Can you post a screen shot?

[KirikauKiwi]

I don't have a MAF sensor connected to my DIYFB currently, I am curious to know that with an otherwise working system sitting statically why I would have a flow difference being displayed, this is with all the calibration data set at the default of 0.00. I would assume that a static system should read zero?

This also lead me to the configuration page to test the offsets etc, I intuitively entered a negative number as I wanted the reading to be lower than displayed it added it to what was already displayed. I entered -13 as the offset expecting to see 0.94 displayed, it went up to 26.94. What feels like a normal convention for everyone, for me it would be to enter a negative number if I wanted to reduced the offset, it would be good to get a consensus on this.

[DeeEmm]

Could be a couple of things...

If you take a look at the configuration tab, you will note that there are settings for minimum flow + pressure. Normally these are set to 1, which means that for all flow values below this threshold, the flow value shown on the GUI will be zeroed down.

There will always be some small +/- fluctuation in value around zero. It will never be perfectly 0.0. So the threshold values act as a filter.

Without a MAF the input value is just floating, so you will generally see some kind of value there. You can try to connect up a potentiometer to mimic the MAF. Using a large value pot like 10k, hook up the outside legs to +5v and GND and connect the middle wiper terminal to the MAF input.

BTW, the zero threshold code may be the reason the flow field does not show -ve values. i.e. it is filtering all values < threshold

[black-top]

I repeated the same test in a few days, and the results looks good. CD flows in 1-2CFM with same calibrations. For cylinder head flow, there are the same problems that we were discussing about filtering. The value fluctuates in the 1–5 CFM range and sometimes in the 5–10 CFM range (with cycle average filter). Maybe turbulence from the cylinder head influences that, but my MAF is far from the cylinder head and 4 or 5 90deg bends, so it should be quite laminar. I was trying to write down minimum values, because it looks like it repeats most accurately. With these results, I think it will be a good option to have at settings to select simple number rounding to a whole number, because the system will probably never be that stable to see less than 1CFM with MAF setup. Also, the"Average Minimum" filter may be worth trying.

[DeeEmm]

I am happy to look at trying some different filters. I think that reading stability is a necessary part of V2, even if it is not specifically written.

The output can be truncated by modifying the following line...

javascript.js approx line 54

            document.getElementById(key).innerHTML = myObj[key].toFixed(2); 

change it to

            document.getElementById(key).innerHTML = myObj[key].toFixed(0); 

Not sure how to integrate this programmatically as it affects the javascript source file. Essentially the javascript file would need to modify itself.

I've made a quick hack to add a couple of variables to the top of the javascript.js file so that it is at least easy to change. But the file will need to be recompiled by gulp. You can also do a search-and-replace in the resultant index.html file within the data folder

var decimalPlacesFlow = 0;
var decimalPlaces = 1;

decimalPlacesFlow relates to all flow values including the differential, whereas decimalPlaces relates to all other values

if (key === 'FLOW' || key === 'AFLOW' || key === 'MFLOW' || key === 'FDIFF'){
  document.getElementById(key).innerHTML = myObj[key].toFixed(decimalPlacesFlow); 
} else {
  document.getElementById(key).innerHTML = myObj[key].toFixed(decimalPlaces); 
}

[DeeEmm]

Okay. so after some experimenting it looks like I can use templating variables in the javascript file which means we can pull these values out into the configuration.

I have also been playing around with the round function to allow us to round to nearest 0.5cfm

round(x * 2.0) / 2.0;

I will package up this up within the configuration settings tab as a new group of settings under the filters

Round to nearest integer Round to nearest 0.5 Decimal places for flow variables 0/1/2 Decimal places for everything else 0/1/2

[black-top]

Tomorrow I will try to edit the index file, and test it on the flow bench, but I'm not sure how to compile the javascript.js file after editing.

[DeeEmm]

To 'compile' the Web UI files, we use GULP. This basically minifies and joins the HTML, Javascript and CSS together in a single GZipped file. It's not really 'compiling' in the true sense. In fact at present I have disabled the minification and GZip as we are in development and we do not have a space issue on SPIFFS. So the co-joined file is currently both humanly readable and easily editable.

You can also just upload the index.html, javascript.js and style.css files to SPIFFS separately via the file interface in the GUI and the code will still work. I've done this to make it easier for anyone who wants to play around with the GUI files.

There is some info in the WIKI on the Web UI files and GULP...

https://github.com/DeeEmm/DIY-Flow-Bench/wiki/WEB-UI

[DeeEmm]

Added rounding / truncation to issue #180

[DeeEmm]

I repeated the same test in a few days, and the results looks good. CD flows in 1-2CFM with same calibrations. For cylinder head flow, there are the same problems that we were discussing about filtering. The value fluctuates in the 1–5 CFM range and sometimes in the 5–10 CFM range (with cycle average filter). Maybe turbulence from the cylinder head influences that, but my MAF is far from the cylinder head and 4 or 5 90deg bends, so it should be quite laminar. I was trying to write down minimum values, because it looks like it repeats most accurately. With these results, I think it will be a good option to have at settings to select simple number rounding to a whole number, because the system will probably never be that stable to see less than 1CFM with MAF setup. Also, the"Average Minimum" filter may be worth trying.

After pondering this last night. I think that this needs further investigation. We should easily be able to get down to sub CFM measurements. We see fractional values in the MAF table and also interpolate the MAF data. If we use simulated input, the readings are very stable, which leads me to think that the fluctuations are external, and potentially hardware related. I think the pulsing that you see when you close off the inlet at 28" is indicative of this. It would be really good to try and isolate the cause.

It would be good to try and pin down the exact cause of the fluctuations. Whilst software filters are an 'easy' solution, they are not taking causality into account. We are only addressing the symptom of the problem and not the problem itself.

Do you have an oscilloscope?. The first step is to determine whether the fluctuations are external to the board. You can monitor the input voltage of the MAF wth a scope to determine this.

Assuming that the fluctuations are external, we then need to determine if they are from the MAF, or as a result of system design, which ideally requires measuring the air flow with a secondary device or monitoring system pressure.

If it is a physical phenomenon, I would expect it to be easily measurable.

If it is not a physical phenomenon, then the solution would be electronic filtering in the form of RC filter(s). There is already a rudimentary RC filter in the design. But the values can easily be tweaked. I think that this would be a more appropriate solution and more robust.

[DeeEmm]

Rather than keep pulling this issue of topic, I would like to close out this issue along with #179 as I feel that these are now both resolved

Lets move discussions related to filtering and smoothing over into https://github.com/DeeEmm/DIY-Flow-Bench/issues/180

[danielerpl]

All good, just finished updating it.

Yes the file upload works perfectly here. Are you using the current versions for both the main code and index.html (in 'data' folder)?

Screen.Recording.2024-11-02.at.5.19.15.pm.mov

If you cannot upload the index.html via the browser then you will need to upload it via VScode

Sure, I am using all the new code from the update mentioned. I already uploaded a screenshot about the result data in the dashboard

[danielerpl]

ok. just to clarify...

we create the raw cfm value from the mass flow...

          sensorVal.FlowKGH = _sensors.getMafFlow();
          sensorVal.FlowCFMraw = _calculations.convertFlow(sensorVal.FlowKGH);

we then apply the leak and flow offsets...

        // Apply Flow calibration and leak offsets
        sensorVal.FlowCFM = sensorVal.FlowCFMraw  - calVal.leak_cal_baseline - calVal.leak_cal_offset  - calVal.flow_offset;

This gives us the main flow value that is displayed in the GUI

The flow differential targets are created like this...

        case USERTARGET:
          sensorVal.FDiff = sensorVal.FlowCFM - calVal.user_offset;

        case BASELINE:
          sensorVal.FDiff = sensorVal.FlowCFMraw - calVal.flow_offset - calVal.leak_cal_baseline;

        case BASELINE_LEAK :
          sensorVal.FDiff = sensorVal.FlowCFMraw - calVal.flow_offset - calVal.leak_cal_baseline - calVal.leak_cal_offset;

Note that the baseline differentials are based on the raw flow value. This avoids applying the offset twice.

So for example if we want to do a leak test, we set the bench up in the same way that we originally undertook the leak calibration (for example blocked off with a plate on the test surface). We can then select the 'Baseline' Flow differential. The resultant value should read zero.

This assumes / requires a few things...

• For initial calibration all offsets are zeroed
• First thing to be calibrated is leak test of bench with seal (or orifice) placed at test surface. This the baseline value
• Next we perform the flow calibration using the test orifice

Later, when we want to calibrate a job for leaks...

• job is placed on test surface
• valves are closed + plugs installed
• inlet ports is sealed with plate (or small orifice)
• This is the leak calibration value (or trim offset as KirikauKiwi describes it)

Note this value needs to be zeroed down for each job as it will change from job-to-job.

This is the basic functionality and flow. Agree that terminology definitely needs to be revised to avoid creating confusion / ambiguity. Would be good to align with language used by other manufacturers.

There is a caveat with this and one that I've gone through a few iterations of code and procedure with.

It is possible to flow test and leak test in any order.

sensorVal.FlowCFM = sensorVal.FlowCFMraw  - calVal.leak_cal_baseline - calVal.leak_cal_offset  - calVal.flow_offset;

Note we do not differentiate between the flow calibration value or the leak calibration value. The are all applied at the same time.

This means that if we first leak test. Then when we do the flow test, the value we store already has the leak test offset applied.

Conversely, if we do the flow test first, and then the leak test, the resultant value will be incorrect.

There is no real way to pick this up without further complicating the code. So at this point in time, it is reliant on people following the correct procedure to calibrate. But it is possible to calibrate in the wrong order and create an error of the magnitude of the leak test.

The new dashboard and the leak test, offset test is making more confusion. It is possible a quick video about the procedure ? What I have in my bench is a negative value and when I do the offset test will be more negative than expected. Also Is not clear for me what is mean the user flow target value. I can understand what is changing in the dashboard but I am not understanding which is the goal of this value