ANOTHER ANOTHER THREAD - SETTING HEATER CONTROL COULDN'T BE EASIER WITH A PROFILUX

[Matthias Gross]

So, instead of getting more involved in endless discussions about hysteresis, nominal values, resulting switching points, alarms, how great it is to enter code instead of just adjusting a few settings, etc. pp I decided to spend a few hours in adding a new feature in our software. It works already in GHL Control Center, I will tell my app guys that they add the same thing next week in our GHL Connect app.

What did I do?
I copied the ProfiLux algorithms, which calculate based on the settings all switching points for a sensor into the GHL Control Center software and display those at the sensor settings page.
How the switching points are calculated are explained in the ProfiLux manual, including examples. But we all don't want to read manuals. I get that.

So this is the result, I believe it is quite self-explanatory. I showed also the state of the outlets which are used for temperature control for easier understanding:
(again - I managed to program it today only for GHL Control Center so please excuse that I show you today only an "old-school" PC software (which is actually preferred by many of our industry and research clients) screenshot and not one from the app, this happens next week)

I marked the relevant settings.

 

[Lasse]

Thank you - Is it implied in the GCC 1.1.4.9 file that is already up on the download site or will it be in a later version of GCC?

I agree - I prefer GCC but the local web page and browser MyGHL is very good nowadays - I use it more and more. The phone app - to monitoring - yes - to do real work - not for me

Sincerely Lasse

 

[Matthias Gross]

No this is in the 1.1.5.0 I will publish in the next days. That new version is required for the new automatic feeder functions. We start shipping the automatic feeders next week, so it is really time to get that version final ...

 

[Lucas815]

Well this is unexpected, and absolutly awesome.

I wish I had more thumbs to raise them all up.

Small things like this makes a world of difference.

 

[BeanAnimal]

So, instead of getting more involved in endless discussions about hysteresis, nominal values, resulting switching points, alarms, how great it is to enter code instead of just adjusting a few settings, etc. pp I decided to spend a few hours in adding a new feature in our software. It works already in GHL Control Center, I will tell my app guys that they add the same thing next week in our GHL Connect app.

What did I do?
I copied the ProfiLux algorithms, which calculate based on the settings all switching points for a sensor into the GHL Control Center software and display those at the sensor settings page.
How the switching points are calculated are explained in the ProfiLux manual, including examples. But we all don't want to read manuals. I get that.

So this is the result, I believe it is quite self-explanatory. I showed also the state of the outlets which are used for temperature control for easier understanding:
(again - I managed to program it today only for GHL Control Center so please excuse that I show you today only an "old-school" PC software (which is actually preferred by many of our industry and research clients) screenshot and not one from the app, this happens next week)

I marked the relevant settings.

Thank you Matthias - this is a small but tremendous interface improvement that will help people. I look forward to it in the app when the programmers get a chance.

Little things like this are much larger improvements than they often appear and I am sure will reduce support and frustration for many of us.

 

[Matthias Gross]

Meanwhile I added this also for all other sensors. Here the calculations are much simpler. The temperature control algorithms are more complex because we must deal with the possibility that someone controls temperature with different methods at the same time: heater + substrate heater + chiller. And it must be avoided that they compete with each other.
That said, all other sensors are much easier, we have only on/off for controlling upwards and downwards.

This looks like that:

 

[KStatefan]

This is great.

Thanks

 

[ingchr1]

Thank you @Matthias Gross. This clears up any questions with the setpoints and other conflicting/unclear/unconcise information that may be out there. It aligns exactly with my observations.

I am one of those who prefer to use GCC over the web and app. I also use both the Heater and Substrate Heater Functions. The Substrate Heater Function is my primary heater (100W), and the Heater Function is my backup heater (50W). I really like the way those two functions operate together.

 

[Matthias Gross]

Thank you @Matthias Gross. This clears up any questions with the setpoints and other conflicting/unclear/unconcise information that may be out there. It aligns exactly with my observations.

I am one of those who prefer to use GCC over the web and app. I also use both the Heater and Substrate Heater Functions. The Substrate Heater Function is my primary heater (100W), and the Heater Function is my backup heater (50W). I really like the way those two functions operate together.

Yes, especially the interaction of of a heater and a substrate heater is a bit tricky, and when we add a chiller it becomes even more complex to switch all devices which are involved in regulating the temperature, all with just one sensor.
A simple "if T > 80 switch off ... if T < 78 switch on" (pseudo-code) just wouldn't do it because we have here overlapping hysteresis (again that bad word) for all 3 devices. And the alarm needs to consider the complete bandwith of all switching points of all involve devices. So the temperature controlling is not as simple as someone might think. That's why we went that way: Set the nominal temperature and leave the rest (switching all connected devices) to the ProfiLux. And if you want to know the details, when does ProfiLux switch what, you have it now, with the newest software addition.

 

[Lasse]

And to this we can add an another total stunning feature of GHL. You can chose among 4 control modes. Two position controller (actual in this thread), Pulse/Pause Fixed, Pulse variable and pause variable. The example below shows a day last year when I wanted (and get) a very stable temperature. The bars indicate when the heater was on. I use the control mode pulse variable for regulating and a virtual doser in order to sample heaters on time. 1 = 1 min. The +0.1 rise in the evening is caused by the light and that my fan is not fast enough. Sample time = 5 min. Temperature = degree C

I nearly always use pulse variable as controller mode (on all parameters that I control a nominal value) because of smother regulation near my nominal value. The downside is that this will cause a lot of switch events done by the relay. During the six years I have used pulse variable with a GHL power hub in my aquarium - I have never need to exchange the relay. I use a 200 W titan heather. That´s quality!

However - with chiller regulation a two position controller function is needed and also a rather large hysteresis. In these cases (heater and chiller) you can use another unique feature - a virtual sensor that copy your real sensor but allow you to have different controller modes and/or different hysteresis for different tasks.

Not to mention the possibility to use a dynamic nominal value, either following an other sensor with or without a ± deviation. It is also possible nowadays to follow a file with different nominal values at different days or/and different times.

Sometimes I feel like it is only the sky that is the limit when you dive deeper into the GHL ecosystem.

Sincerely Lasse

 

[ingchr1]

Yes, especially the interaction of of a heater and a substrate heater is a bit tricky, and when we add a chiller it becomes even more complex to switch all devices which are involved in regulating the temperature, all with just one sensor.
A simple "if T > 80 switch off ... if T < 78 switch on" (pseudo-code) just wouldn't do it because we have here overlapping hysteresis (again that bad word) for all 3 devices. And the alarm needs to consider the complete bandwith of all switching points of all involve devices. So the temperature controlling is not as simple as someone might think. That's why we went that way: Set the nominal temperature and leave the rest (switching all connected devices) to the ProfiLux. And if you want to know the details, when does ProfiLux switch what, you have it now, with the newest software addition.

I use the Cooling Function with my PropellerBreeze.

One suggestion on the cooling and alarm setpoints, I think they would benefit from a reset band. Explanation; let's say the upper setpoint is 80.0F, as soon as the temperature hits 80.0F they actuate, but as soon as temperature drops to 79.9F they clear. This results in the alarm/cooling cycling until the temperature is a hard 80.0F or 79.9F. I've seen this numerous times on my tank with a rising temperature condition. My cooling is the PropellerBreeze, so not much of an issue there. But the alarm can get annoying when it's cycling in and out. Would be much better if the reset was at least 0.2F from the setpoint, above for lower setpoint and below for upper setpoint. Another solution would be to require that the parameter is stable for some set period of time before setpoint actuation.

 

[Matthias Gross]

Why don't you just use a larger band for the alarm? Which is large enough to not trigger alarms under normal conditions, but triggers an alarm when the temp. becomes really too high (or low).
I wouldn't know how to implement what you suggested, and honestly I didn't really understand... and what I don't understand I can program. And I don't want more settings, as we see the amount of settings we already have is sometimes confusing for some. It must be easy. When alarm is going on and off (because the temp. is at the threshold) on a regular basis then the solution is not to suppress the alarm with some tricks, then it is better to review and adapt the settings, or the conditions.

 

[ingchr1]

Why don't you just use a larger band for the alarm? Which is large enough to not trigger alarms under normal conditions, but triggers an alarm when the temp. becomes really too high (or low).
I wouldn't know how to implement what you suggested, and honestly I didn't really understand... and what I don't understand I can program. And I don't want more settings, as we see the amount of settings we already have is sometimes confusing for some. It must be easy. When alarm is going on and off (because the temp. is at the threshold) on a regular basis then the solution is not to suppress the alarm with some tricks, then it is better to review and adapt the settings, or the conditions.

Just a suggested improvement, from how I've seen control systems setup in the industries I have worked in (utilities, internet data centers, nuclear power). The alarm points all have a hysteresis applied to them, so this type of cycling does not occur. The setting wouldn't even have to be visible or adjustable by the end user. Once a setpoint is triggered it just wouldn't reset until 0.2C from setting, for example. This can be explained in the documentation.

If this is something that you do not see as necessary or would be a very low priority on your list of things to do, that is fine, but it is not some trick and just changing the setting is not really the ideal approach either.

 

[KStatefan]

FYI
1.1.5.0 is available to download today

 

[TehBrainz]

No this is in the 1.1.5.0 I will publish in the next days. That new version is required for the new automatic feeder functions. We start shipping the automatic feeders next week, so it is really time to get that version final ...

Updated my GCC and love this new feature. Also excited for the new feeder! Should be ordering in the coming weeks

Thank you @Matthias Gross and the GHL team!

 

[Lasse]

FYI
1.1.5.0 is available to download today

I will remember all to save all settings before installing this FW for P4 (7.40). I did not do it on my spare P4 and it reset to default. No harm because it was not programmed. I do not know f this is valid for all - that it reset to default - but a warning does not hurt. Always save settings and sensordata before FW update.

Sincerely Lasse

 

[ingchr1]

I will remember all to save all settings before installing this FW for P4 (7.40). I did not do it on my spare P4 and it reset to default. No harm because it was not programmed. I do not know f this is valid for all - that it reset to default - but a warning does not hurt. Always save settings and sensordata before FW update.

Sincerely Lasse

And also remember to restore any virtual probes that you may have.

 

[Ky_acc]

This is an excellent update!

I’m very impressed that you’ve taken the time to implement this - great improvement.

I just saw this so looking forward to downloading and playing around with this

 

[Herbster]

I will remember all to save all settings before installing this FW for P4 (7.40). I did not do it on my spare P4 and it reset to default. No harm because it was not programmed. I do not know f this is valid for all - that it reset to default - but a warning does not hurt. Always save settings and sensordata before FW update.

Sincerely Lasse

Yes, I thought I had a recent backup but could only find one from 6 months ago and my update ended with an error and I had to restore back.