Jump to content

Recommended Posts

Good morning,
I have the V350 for a month and I have already made several programs.
I want to create a weekly timer thermostat.
The operator must be able to set ->
es
Monday from 10:00 to 12:00 I want to 20 ° C
Monday from 13:00 to 16 I want 21 ° C
Tuesdays from 10:00 to 12:00 I want to 18 ° C
Etc. etc..

I tried it with data tables, can be a way ...
but you can not see the table on the screen in any way !!!!!

Link to comment
Share on other sites

  • MVP 2023

Unfortunately, there is no data table screen object.  I really wish there was but that's not going to happen.

If you want to use data tables for storage you have to read and write row values to MIs for display on the screen.

Do you want a different set of setpoints for each day of the week?  How many setpoints per day can they have?  Will you pass through midnight with the same setpoint?

I would make an hour generator for the whole week (168 hours) and then look up the setpoint based on the hour of the current week, resetting the hour counter at midnight on Saturday.  It would make looking up the sepoint easy.

You could display day and time based on the hour value.

Post one of you programs so we can see what you've done.

Joe T.

Link to comment
Share on other sites

  • MVP 2023

This is very simple.

You need to use the function on the menu under Utils/Clock/Direct Clock Functions/Day of the Week in series with the function Time (found in the same place) to store 20 in an MI for the thermostat setting for Monday 10:00 to 12:00. Do the same for each separate setting you desire.

You can use indirect values anywhere you want to have an operator input, whether for the time settings or the thermostat settings.

Link to comment
Share on other sites

  • MVP 2023

Hi Jxay,

I don't think this is as simple as it first looks.  And Flex, don't you mean Indirect clock functions, given the need to be able to let the user adjust things on screen?

My main work is HVAC and I use Unitronics for complex applications where off the shelf DDC stuff isn't flexible enough.  I'm assuming that your program itself will do differentials around the setpoint according to presets.  I also see issues where you might have large temp changes between time zones, which are probably best handled by the program ramping the temp between old and new, otherwise your systems may heat or cool unnecessarily, and uncomfortably.  In this I'm assuming the temp control is for humans' benefit!

As for the mechanics of the program, it all comes down to how much maths and programming you want to do.  The simplest method is pretty much Joe's weekly hour count suggestion, having a screen or screens for each day, showing the setpoint for each hour period of that day.  This is a bit cumbersome from the human's data entry viewpoint as they have to input/agree to each hour's temp setting, but it is simple program writing.  It does restrict things down to changes on the hour, though. 

Method 2 is if you are willing to do a lot of maths and complexity in the program, you can again have the users in control of a daily screen.  This daily input automatically calculates the time into the weekly hour count...but it is essentially user generated and down to the minute.  The times they enter are actual times based around 24 hour naming.  eg 230 for 02:30am and 1345 for 1:45pm.  Your user then agrees to/enters the start and end time and setpoint into fields on the screen, and the program automatically reads the finish time and puts it into the start time for the next period and displays everything already done for that day.  Having the program move the end time to the next start time is important, as it gets around the issue of overlaps. It ends up at 2359 for each day's end and then the input screens start again for the next day.  You either do the time storage based on what day it is, or do the total weekly count style again.    My initial thoughts are that this would still need to have a maximum number of setpoints per day otherwise things are going to get very complex, but perhaps once into actual writing the program this might not be as hard.  You put the time zones and temps into a spaced series of MIs that are then displayed according to how many are in use.   You are also going to have to work up a rolling compare program to change the setpoint in use according to the RTC time.

Hope you get the idea.  I've just rattled this off.  I call this a terrific learning curve.  You might call it an "ohh.....what have I got myself into?!"

cheers,

Aus

Link to comment
Share on other sites

  • MVP 2023

You've learned one of the PLC truths - they are a blank slate and their function is TOTALLY up to the programmer.  There are no canned programs that fit everyone's needs, because at the end of the day a seemingly simple requirement has a little user twist - like your requirement for different temperatures on different days of the week.

I don't know if you can adapt a commercial product, but I did a little searching on programmable thermostats and found a Honeywell RTH8500D that allows four setpoints on each of seven days-

http://yourhome.honeywell.com/en/products/thermostat/7-day-programmable-thermostat-rth8500d

It was definitely an interesting discussion!

Joe T.

Link to comment
Share on other sites

  • MVP 2023

Yep, Honeywell's programmers have done it all for you on that one, including the fuzzying of the logic to learn your system's abilities.

However, a V350 will certainly do what you want with some effort put into it. For now you could do the simple hourly verson quite easily and evolve the other versions over the months ahead.

Good luck.

Aus

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

This site uses cookies. By clicking I accept, you agree to their use.