storunner13
Well-Known Member
Thanks for the input. Sounds like that will be the plan for me too. Keep it simple.
BruControl: Brewery control & automation software
- Thread starter BrunDog
- Start date
Help Support Homebrew Talk:
MightyOz
Local Storm Brewing
I should be grateful for some help with my BruControl Setup for fermenting please.
I am using an Arduino Mega, 2 x PT100 with Adafruit Max31865 shields, and standard 6 x Arduino type relay board, and the issue is that during my first trial run.
Everything is stable when idling, as well as when cooling is called for, but when the heat is activated my temperature sensor / reading then goes haywire (generally in the minus range) for about 10 to 30 seconds or so (see photo) before it re-stabilises.
The situation appears to be an issue that just happens on the FV1 side, as the FV2 side appears stable.
Therefore, I should be grateful for your thought on what could be the issue with my system please? Thanks.
I am using an Arduino Mega, 2 x PT100 with Adafruit Max31865 shields, and standard 6 x Arduino type relay board, and the issue is that during my first trial run.
Everything is stable when idling, as well as when cooling is called for, but when the heat is activated my temperature sensor / reading then goes haywire (generally in the minus range) for about 10 to 30 seconds or so (see photo) before it re-stabilises.
The situation appears to be an issue that just happens on the FV1 side, as the FV2 side appears stable.
Therefore, I should be grateful for your thought on what could be the issue with my system please? Thanks.
Is the heat source common for both FV1 and FV2 or individual ? If individual maybe try swapping them both (heat sources) and see if the problem changes with the exchange.
Last edited:
Do you have good separation of wires/cables between your relay and PT100 filter, I'm wondering if this is an EMI issue? When heating is called for it may be causing a spike which translates over to one of your PT cables/leads thus causing the negative reading.
![Craft A Brew - Safale S-04 Dry Yeast - Fermentis - English Ale Dry Yeast - For English and American Ales and Hard Apple Ciders - Ingredients for Home Brewing - Beer Making Supplies - [1 Pack]](https://m.media-amazon.com/images/I/41fVGNh6JfL._SL500_.jpg)
Hi Tartan1, Thanks for your prompt reply, and although there is some separation between the wires, but you could be right with an EMI issue. I will look at move the MAX31865’ away from some nearby cabling. Thanks again.
Hi, Yes, I believe that it is an EMI issue, especially when a 12volt coiled relay triggers a 240 volt appliance, such as heater and the 240v external glycol pump.
However, what type of "Vasistor" do you recommend for 240 volts, as I am sorry that I am struggling to understand the guidance on https://brucontrol.com/wp-content/uploads/2018/08/BruControl-EMI-Protection-Schematics.pdf?
Thanks again for your help.
However, what type of "Vasistor" do you recommend for 240 volts, as I am sorry that I am struggling to understand the guidance on https://brucontrol.com/wp-content/uploads/2018/08/BruControl-EMI-Protection-Schematics.pdf?
Thanks again for your help.
Doing my monthly backuo to dropbox. If you do NOT have a good backup plan, you will not be happy one day. There is an automated backup in BruControl ( to your local drive) which is great, but one day that might not be enough!
storunner13
Well-Known Member
I'm switching to a proportional SSR -- specifically the Crydom PMP2425w. Can I run this with 5v PWM (not duty cycle) alone? Or should I convert the signal to an analog 0-5v in front of the PSSR?
- Joined
- Mar 24, 2016
- Messages
- 558
- Reaction score
- 60
I don’t use one but from the specs it seems you’ll need to convert to analog.
^definitely^ needs an "analog" transfer control input which can take many forms: 0-5 VDC, 0-12 VDC, 4-20ma (<- that one takes me back about five decades 
). Not a pulse width control thing...
https://www.mouser.com/datasheet/2/...s_proportional_control_ssr_datash-2933900.pdf
Cheers!
). Not a pulse width control thing...https://www.mouser.com/datasheet/2/...s_proportional_control_ssr_datash-2933900.pdf
Cheers!
storunner13
Well-Known Member
Thanks all. I'll wire it through the analog converter module.
It's been a while since I shared here, mostly because BC continues to run great, and my setup has been stable.
Problem
That said, I kept having issues with Tilt accuracy, as changing the battery throws off its original calibration, which is why the Tilt/Tilt2 app has its own calibration means. I was getting frustrated with changing my offset each time I measured my wort with my EasyDens to maintain some level of accuracy since 1) that wastes wort and 2) Supabase database carries inaccurate numbers until I adjust it (and I want some accuracy for a personal phone app and data analysis project I am doing).
Solution approach
Calibrating the Tilt for BC has been covered a bit in this thread, but I wanted to offer my approach to get it accurate enough for government work without having to calibrate with a custom wort/sugar solution each time the battery is changed and without using a CSV in a lookup table. It requires a script, and the Tilt must be properly calibrated in pure water (with another gravity tool, like an EasyDens, agreeing the water is 1.000).
Assumptions
I work from the assumption that Tilt calibrates it at the factory with the OEM battery, hardcoding both the highest calibration (e.g., 1.120) and lowest (1.000). From there, the assumption is that Tilt uses a linear scale factor to convert X-degree of angle to Y gravity. Since the Tilt can't have the upper calibration changed, we have to work with whatever it thinks the scale is between the highest calibration and the new 1.000. If the battery weight makes that scale factor smaller or larger, we have to deal with it. But it is still linear in some way.
With that, since gravity drop is also linear, we can use the OG of the wort to set our own scale factor, where the Tilt is the independent variable, and the actual SG (as referenced by an EasyDens or standard hydrometer, for example) is the dependent variable. By working from the OG of the given beer, you don't have to do a full-scale calibration when you change the battery (e.g., making a solution with a known gravity and getting what the Tilt thinks it is). It gets enough precision to make the Tilt data meaningful for whatever need. You also don't need to use a look-up table or spreadsheet (though, I use an Excel sheet with similar math below to see what I should expect so I can check my script works well).
I hope this helps someone else who battles Tilt accuracy issues after changing the battery.
BC setup for the code
To start, you need your Tilt device setup without any calibration properties. You also need three globals: one for your Tilt's OG measurement, one for the actual OG (as measured by other means), and one for your adjusted SG value. Mine is automatically set based on Brewfather data, but you can just set the global in BC when you are transferred to the fermenter.
The code
You can use and adjust this script accordingly for your layout/format. For me, "BB1" is used at the beginning of all my devices and globals for my BrewBuilt fermenter (1 being used to distinguish a potential future 2nd BrewBuilt fermenter; I do the same for my Spike and Fermzilla fermenters).
Now, you should see what the gravity is with better accuracy and use that adjusted SG global for whatever you need (e.g., show on a custom site/app, push to Brewfather, trigger fermenter actions, etc.).
Limitations
As the calibration is based on OG readings of the Tilt and other means, the scale value is less precise than if you made a high-gravity solution and calculated a static scale value until the battery is changed again. But I don't want to make unnecessary high-gravity wort for this, and this has so far been accurate enough for (as a DC resident) government work.
My random gravity readings during fermentation using my EasyDens has returned the expected gravity readings based on this script within one gravity point, and that's just due to rounding, which we can't really control.
Even cooler would be if we could set the Tilt device's calibration functions via script to not have to use a global for the adjusted value, e.g.:
"BB1 Tilt" offset = -1
"BB1 Tilt" linearmultiplier = ration,
"BB1 Tilt" offset = +1)
But I get how tricky it would be when the calibration values in the properties have to be set in order and stored for the device.
Problem
That said, I kept having issues with Tilt accuracy, as changing the battery throws off its original calibration, which is why the Tilt/Tilt2 app has its own calibration means. I was getting frustrated with changing my offset each time I measured my wort with my EasyDens to maintain some level of accuracy since 1) that wastes wort and 2) Supabase database carries inaccurate numbers until I adjust it (and I want some accuracy for a personal phone app and data analysis project I am doing).
Solution approach
Calibrating the Tilt for BC has been covered a bit in this thread, but I wanted to offer my approach to get it accurate enough for government work without having to calibrate with a custom wort/sugar solution each time the battery is changed and without using a CSV in a lookup table. It requires a script, and the Tilt must be properly calibrated in pure water (with another gravity tool, like an EasyDens, agreeing the water is 1.000).
Assumptions
I work from the assumption that Tilt calibrates it at the factory with the OEM battery, hardcoding both the highest calibration (e.g., 1.120) and lowest (1.000). From there, the assumption is that Tilt uses a linear scale factor to convert X-degree of angle to Y gravity. Since the Tilt can't have the upper calibration changed, we have to work with whatever it thinks the scale is between the highest calibration and the new 1.000. If the battery weight makes that scale factor smaller or larger, we have to deal with it. But it is still linear in some way.
With that, since gravity drop is also linear, we can use the OG of the wort to set our own scale factor, where the Tilt is the independent variable, and the actual SG (as referenced by an EasyDens or standard hydrometer, for example) is the dependent variable. By working from the OG of the given beer, you don't have to do a full-scale calibration when you change the battery (e.g., making a solution with a known gravity and getting what the Tilt thinks it is). It gets enough precision to make the Tilt data meaningful for whatever need. You also don't need to use a look-up table or spreadsheet (though, I use an Excel sheet with similar math below to see what I should expect so I can check my script works well).
I hope this helps someone else who battles Tilt accuracy issues after changing the battery.
BC setup for the code
To start, you need your Tilt device setup without any calibration properties. You also need three globals: one for your Tilt's OG measurement, one for the actual OG (as measured by other means), and one for your adjusted SG value. Mine is automatically set based on Brewfather data, but you can just set the global in BC when you are transferred to the fermenter.
The code
You can use and adjust this script accordingly for your layout/format. For me, "BB1" is used at the beginning of all my devices and globals for my BrewBuilt fermenter (1 being used to distinguish a potential future 2nd BrewBuilt fermenter; I do the same for my Spike and Fermzilla fermenters).
Code:
//Initialize the local script variables
new value oldTilt //Gets what the Tilt device shows so the script will trigger when the value changes
new value ogEasyDens //My measured OG, which I get from my EasyDens
new value ogEasyDens2 //Used for some math
new value ogTilt //What the Tilt showed at the start of fermentation
new value ogTilt2 //Used for some math
new value ratio //My scale factor
new value sgTilt //What the Tilt currently shows
new value sgAdj //The new SG value when set back to an actual SG format
oldTilt = "BB1 Tilt" SG //Set what the starting Tilt value is at when the script starts
[Loop]
wait "BB1 Tilt" SG != oldTilt //Wait until the Tilt's shown value doesn't match the old one
oldTilt = "BB1 Tilt" SG //Reset the oldTilt value so this can trigger again on the next change
ogTilt = "BB1 Tilt OG" value //Get data from the global used to store the Tilt's OG value
ogTilt2 = ogTilt - 1 //Subtract 1 so you are left only with the decimal value (or "gravity points")
ogEasyDens = "BB1 OG" value //Get data from the global used to store the actual OG value
ogEasyDens2 = ogEasyDens - 1 //Subtract 1 so you are left only with the decimal value (or "gravity points")
ratio = ogEasyDens2 / ogTilt2 //Calculate the scale ratio (the slope... dependent variable over the independent variable)
ratio precision = 6 //Get more precision out of the ratio for more accuracy in the new value (i.e.., minimize inaccurate rounding)
sgTilt = "BB1 Tilt" SG - 1 //Get the current Tilt value and subtract 1, leaving only the decimal value (or "gravity points")
sgAdj = sgTilt * ratio //Multiply the gravity points by the scale value
sgAdj precision = 6 //Adjust to 6 decimals of precision to limit rounding
sgAdj += 1 //Add the 1 back to show an actual gravity value
"BB1 Gravity" value = sgAdj //Set the adjusted gravity global to the calculated actual SG value
goto "Loop" //Return to loop and wait for the Tilt to have a change in its valueNow, you should see what the gravity is with better accuracy and use that adjusted SG global for whatever you need (e.g., show on a custom site/app, push to Brewfather, trigger fermenter actions, etc.).
Limitations
As the calibration is based on OG readings of the Tilt and other means, the scale value is less precise than if you made a high-gravity solution and calculated a static scale value until the battery is changed again. But I don't want to make unnecessary high-gravity wort for this, and this has so far been accurate enough for (as a DC resident) government work.
My random gravity readings during fermentation using my EasyDens has returned the expected gravity readings based on this script within one gravity point, and that's just due to rounding, which we can't really control.
Even cooler would be if we could set the Tilt device's calibration functions via script to not have to use a global for the adjusted value, e.g.:
"BB1 Tilt" offset = -1
"BB1 Tilt" linearmultiplier = ration,
"BB1 Tilt" offset = +1)
But I get how tricky it would be when the calibration values in the properties have to be set in order and stored for the device.
Last edited:
I was looking over this and changed a little so it made sense to me using my camel code
My code:
new value vVoldTilt //Gets what the Tilt device shows so the script will trigger everytime the Tilt value changes
new value vVogExternal //My measured OG, which I get from my EasyDens
new value vVogExternal_2 //Used for some math
new value vVogTilt_1 //What the Tilt showed at the start of fermentation
new value vVogTilt_2 //Used for some math
new value vVratio //My scale factor
new value vVsgTilt //What the Tilt currently shows
new value vVsgAdj //The new SG value when set back to an actual SG format
vVoldTilt = "2" SG //Set what the starting Tilt value is at when the script starts it will make first reading then with every change
[Loop]
//my Green Tilt is on my My Main Brewery Mega at port 220 (MB_220_)
wait "MB_220_Green_Tilt" SG != vVoldTilt //Wait until the Tilt's shown value doesn't match the old one
vVoldTilt = "MB_220_Green_Tilt" SG //Reset the vVoldTilt value so this can trigger again on the next change
//*******************************************************************************************************
//*******************************************************************************************************
vVogTilt_1 = "gblV_Green_Tilt_OG" value //Get data from the global used to store the Tilt's OG value
//*******************************************************************************************************
//*******************************************************************************************************
vVogTilt_2 = vVogTilt_1 - 1 //Subtract 1 so you are left only with the decimal value (or "gravity points")
vVogExternal = "gblV_External_OG" value //Get data from the global used to store the actual OG value
vVogExternal_2 = vVogExternal - 1 //Subtract 1 so you are left only with the decimal value (or "gravity points")
vVratio = vVogExternal_2 / vVogTilt_2 //Calculate the scale vVratio (the slope... dependent variable over the independent variable)
vVratio precision = 6 //Get more precision out of the vVratio for more accuracy in the new value (i.e.., minimize inaccurate rounding)
vVsgTilt = "MB_220_Green_Tilt" SG - 1 //Get the current Tilt value and subtract 1, leaving only the decimal value (or "gravity points")
vVsgAdj = vVsgTilt * vVratio //Multiply the gravity points by the scale value
vVsgAdj precision = 6 //Adjust to 6 decimals of precision to limit rounding
vVsgAdj += 1 //Add the 1 back to show an actual gravity value
"gblV_Green_Tilt_SG" value = vVsgAdj //Set the adjusted gravity global to the calculated actual SG value
goto "Loop" //Return to loop and wait for the Tilt to have a change in its value
What I do not understand is the
//*******************************************************************************************************
//*******************************************************************************************************
vVogTilt_1 = "gblV_Green_Tilt_OG" value //Get data from the global used to store the Tilt's OG value
//*******************************************************************************************************
//*******************************************************************************************************
where does gblV_Green_Tilt_OG gets its datapoint? Is it a measured value that uou input to the global? I have not messed with my tilts but will shortly.
Hah, love seeing the differences in setups and global/device names. That's what makes BruControl so great. You can truly choose your own adventure (and run your water sprinklers with it, if you wanted)
If you can think it, you can likely do it!
Hey all...started getting my feet wet with scripting last night and of course I've immediately hosed myself by endlessly looping an auto-starting script. This has led to my Brucontrol application freezing and becoming unresponsive which requires me to kill it with Task Manager...similar to what @oakbarn experienced here: https://www.homebrewtalk.com/thread...trol-automation-software.624198/post-10284815
Can someone tell me where the scripts are saved within the app so that I can remove it and get back to breaking something else?
Can someone tell me where the scripts are saved within the app so that I can remove it and get back to breaking something else?
You can restore an old config file (e.g., yesterday's). But that'll undo any changes you made in BC since that file was created.
Alternatively, make a copy of the current default.brucfg version as a fresh backup, and then in the original file, search in for the code element. Make sure to remove all open and closing tags related to it.
Looking at mine, you'd likely want to start with the <Process> tag before that code and end at the </Process>.
You could also just resolve the issue by inserting "sleep 1000" for it to not do the spiral death loop (that gives you a 1 second delay), or use "wait" if it can be event-based.
@CDCTx I'll probably take your second suggestion and look through the config to remove the broken script (or add the delay like you mentioned).
I'm on a Windows host with a default install of Brucontrol...where are the configs saved? I have hidden files turned on and don't any cfg files...just a bunch of .dlls for Brucontrol.
Ah, look in your Documents folder. There should be a "Brucontrol" folder there. Then look for default.brucfg and go from there
Easiest is to replace with a config file prior to your endless loop. A sleep us a good idea in a loop but you can also create a loop killer if statement
You need a global value. Such as “gblVLoopKiller”
In your loop put an if statement
If “glbVLoopKiller” value >= 1
stop “yourScriptname”
endif
I put this in all my loops. If I need to do a kill, I just manually change the value of my global.
There is a folder named BruControl
There is a sub folder named configBackup
You will find all the auto backups there. You need to copy the backup you want to the BruControl folder
You then need to change the name of the offending .brucfg file to something else or just delete it. Change the name of the backup file to what your config file was. Generally by getting rid of the backup extension. To be usable a config file must end with .brucfg
There is a sub folder named configBackup
You will find all the auto backups there. You need to copy the backup you want to the BruControl folder
You then need to change the name of the offending .brucfg file to something else or just delete it. Change the name of the backup file to what your config file was. Generally by getting rid of the backup extension. To be usable a config file must end with .brucfg
@oakbarn @CDCTx , you guys rock, thanks.
While I'm back online...(I turned off the autostart for the script)...I can't figure out why this script isn't running:
[Prime_Pump_1]
start "Prime_Pump_1"
print = "Starting Pump_1 prime cycle."
"Valve_11" State = on
sleep 4000
"Pump_1" State = on
"Valve_14" State = on
sleep 10000
print = "Prime complete, closing valves and shutting off pump."
"Valve_14" State = off
"Pump_1" State = off
"Valve_11" State = off
print = "Terminating Pump_1 prime cycle."
stop "Prime_Pump_1"
It just flips back-and-forth between start and the first print statement.
Any ideas?
While I'm back online...(I turned off the autostart for the script)...I can't figure out why this script isn't running:
[Prime_Pump_1]
start "Prime_Pump_1"
print = "Starting Pump_1 prime cycle."
"Valve_11" State = on
sleep 4000
"Pump_1" State = on
"Valve_14" State = on
sleep 10000
print = "Prime complete, closing valves and shutting off pump."
"Valve_14" State = off
"Pump_1" State = off
"Valve_11" State = off
print = "Terminating Pump_1 prime cycle."
stop "Prime_Pump_1"
It just flips back-and-forth between start and the first print statement.
Any ideas?
For 'start "Prime_Pump_1",' are you trying to start another script or some timer? It seems like this script is the pump 1 priming script, so just need to know what is being started
@CDCTx lol, I see why you say that now...I thought I needed start/stop for the script itself...now I see that start/stop are specific to Timers (RTFM)
Updated script:
[Prime_Pump_1]
print = "Starting Pump_1 prime cycle."
"Valve_11" State = on
sleep 4000
"Pump_1" State = on
"Valve_14" State = on
sleep 10000
print = "Prime complete, closing valves and shutting off pump."
"Valve_14" State = off
"Pump_1" State = off
"Valve_11" State = off
print = "Terminating Pump_1 prime cycle."
Does it play nice now?@CDCTx lol, I see why you say that now...I thought I needed start/stop for the script itself...now I see that start/stop are specific to Timers (RTFM)
Updated script:
[Prime_Pump_1]
print = "Starting Pump_1 prime cycle."
"Valve_11" State = on
sleep 4000
"Pump_1" State = on
"Valve_14" State = on
sleep 10000
print = "Prime complete, closing valves and shutting off pump."
"Valve_14" State = off
"Pump_1" State = off
"Valve_11" State = off
print = "Terminating Pump_1 prime cycle."
And yeah, the start/stop statements are used for other scripts or timers. I have an "overall" script for each fermenter that, based on the respective "Ferm Status" being true or false, either starts all my associated scripts and enables devices or stops/disables. That script is always running (using a wait statement).
So in your case, you may want a script that enables and disables this script based on certain conditions, or you may want to add a button or switch to your interface, and the script can watch for them to be set to true before doing a thing
//Prime_Pump_1
//Starting Pump_1 prime cycle.
"Valve_11" State = on
sleep 4000
"Pump_1" State = on
"Valve_14" State = on
sleep 10000
// Prime complete, closing valves and shutting off pump.
"Valve_14" State = off
"Pump_1" State = off
"Valve_11" State = off
// Terminating Pump_1 prime cycle.
stop Prime_Pump_1
I would use CamelCode for the Element Names
I ilke to give them somewhat meaningful names
as an example for your pump
Lets say it in on you Main Brewery Interface (Audrino) a digital out on port 40 and it is on my Main Brewery Workspace
I would name it
MB_40_do_Pump_1_Main and use a display name of Pump 1 or what ever you like,
MB - Main Brewery Inteface
_40 = port 40
do_= digital out
Pump_1+ is plain what it is
Main is the workspace This realy helps to find it on the screen~!
use the display name for the screen appearance.
I have found this very helpful and insures a unique name and no conflicts in scripts beween a name an an object (like an element).
//Starting Pump_1 prime cycle.
"Valve_11" State = on
sleep 4000
"Pump_1" State = on
"Valve_14" State = on
sleep 10000
// Prime complete, closing valves and shutting off pump.
"Valve_14" State = off
"Pump_1" State = off
"Valve_11" State = off
// Terminating Pump_1 prime cycle.
stop Prime_Pump_1
I would use CamelCode for the Element Names
I ilke to give them somewhat meaningful names
as an example for your pump
Lets say it in on you Main Brewery Interface (Audrino) a digital out on port 40 and it is on my Main Brewery Workspace
I would name it
MB_40_do_Pump_1_Main and use a display name of Pump 1 or what ever you like,
MB - Main Brewery Inteface
_40 = port 40
do_= digital out
Pump_1+ is plain what it is
Main is the workspace This realy helps to find it on the screen~!
use the display name for the screen appearance.
I have found this very helpful and insures a unique name and no conflicts in scripts beween a name an an object (like an element).
@CDCTx it is playing nice.
It was literally my first script...just trying to open a few valves ,run the pump for a few seconds to avoid cavitation, and shut everything back down...and of course I broke it.
Thanks for the advice on everything so far...I'm sure I'll be back.
@oakbarn noted...I'll certainly implement this sort of naming convention to keep everything straight and easy to locate...I have seen lots of other people's scripts in this forum and was always perplexed at the cryptic names people used...now it makes sense
Awesome! It was a good learning experience, clearly, and now you see the app's config structure. The documentation is very helpful, and you can get creative with the very simple script language.@oakbarn noted...I'll certainly implement this sort of naming convention to keep everything straight and easy to locate...I have seen lots of other people's scripts in this forum and was always perplexed at the cryptic names people used...now it makes sense
For naming, yes, it's interesting to see the variation. I use BC for the cold side only. Each workspace is the fermenter name (Spike 1, BrewBuilt 1, Fermzilla 1), and everything is then based on abbreviations of those. So on the Spike 1 (SP1) workspace, I have SP1 Tilt, SP1 Temperature, SP1 PSI, etc. Since I have the same control setup across all fermenters, when I make a script to manage some fermentation aspect, I can write a script for one fermenter, test it, then copy that code into new scripts for the other fermenters (using Ctrl + H to replace, e.g., SP1 with BB1). Script names also use the abbreviations, but to keep them from clashing with element/global names, I always add "Script" at the end of the script name.
Hi All,
Been away from the brewhouse for a while and on to a new automation project before re-starting the brewery. Not sure where to post this query as it is not related to brewing, but it is linked to Brucontrol (Mega 2560)- I am working on automating a diesel irrigation pump. I am building a small scale simulator for now and I need to read an RPM value by measuring gear tooth via a Hall Effect sensor (data sheet attached). This sensor should provide a square wave digital output. It has 3 wires - ground, Vdc In (5 Vdc supplied) and signal. I connected the signal to pin A1 (port55) as an Analog Input and I read 4.36 V with a metal target far, and 0.0V with metallic target near.
I get a reading on my related Brucontrol Element, but it seems like the refresh rate is too slow - there's an delay which makes the reading unusable when moving the target in and out of range - by hand - my Element essentially always shows target far unless I slow down the movement dramatically.
Any suggestion on how to obtain a reading fast enough to count gear teeth on a rotating flywheel with my Brucontrol?
Been away from the brewhouse for a while and on to a new automation project before re-starting the brewery. Not sure where to post this query as it is not related to brewing, but it is linked to Brucontrol (Mega 2560)- I am working on automating a diesel irrigation pump. I am building a small scale simulator for now and I need to read an RPM value by measuring gear tooth via a Hall Effect sensor (data sheet attached). This sensor should provide a square wave digital output. It has 3 wires - ground, Vdc In (5 Vdc supplied) and signal. I connected the signal to pin A1 (port55) as an Analog Input and I read 4.36 V with a metal target far, and 0.0V with metallic target near.
I get a reading on my related Brucontrol Element, but it seems like the refresh rate is too slow - there's an delay which makes the reading unusable when moving the target in and out of range - by hand - my Element essentially always shows target far unless I slow down the movement dramatically.
Any suggestion on how to obtain a reading fast enough to count gear teeth on a rotating flywheel with my Brucontrol?
I am trying to figure out dead band elements.
I cannot get a the dead band element to be enabled via a script
"my Dead Band Element" enabled = true
No error, but Element is not emabled.
I cannot get a the dead band element to be enabled via a script
"my Dead Band Element" enabled = true
No error, but Element is not emabled.
No error, no issue! I had the port duplicated!
ClaudiusB
Well-Known Member
I am not familiar with the Mega 2560. My system can handle up 7kHz at its input, but I use a simple approach any system should handle. One pulse per revolution is all I look for to tell me my grain mill is alive and turning.
Attachments
Use an edge triggered interrupt?
I use a Mega2560 as the heart of my Reverse Osmosis controller which needs to count flow meter pulses at a rather slow pace given the ~4 GPH flow rate. I used edge triggered interrupts and it's been working great for years...
Cheers!
I use a Mega2560 as the heart of my Reverse Osmosis controller which needs to count flow meter pulses at a rather slow pace given the ~4 GPH flow rate. I used edge triggered interrupts and it's been working great for years...
Cheers!
Nice setup. Seems like my project would be easier using a magnet or some other kind of marking on one single flywheel tooth - which I believe is the concept you are using for your motor. Not really possible with my flywheel - all tooth are identical..
can an edge triggered interrupt be used on a digital input on Brucontrol?
Similar threads
