Slow PWM programming


I want to modulate my underfloor heating by triggering the valves on a 100s base time

My idea is to do the code as following
10 IF INTERVAL ( 00:00:01 ) THEN GOSUB 30

20 END

30 REM CODE EXECUTED EVERY SECOND , 100 is the period

40 IF W < 100 THEN W = W + 1 ELSE W = 0

100 REM S01 is the valve command output W01 is the percentage of time it should run

110 S01 = W < W01



For me line 110 and 120 are equivalent and 110 is easier to read. Are they both accepted by control basic syntax ?

Is there a better approach to do this ?

Thanks for your feedback

I am not a fan of gotos, all programs in general need to run through to the end without jumping back on themselves. the reason for this is that the T3 controller buffers the output state till the last line of the program and as the code exits it will write the state of the outputs to the actual hardware. A program that never exits is not going to function well if at all.

So here’s the way I would suggest and its very simple thanks to the built in timing functions:

First fill in the name of the input, output and create a few variables to hold the valve timers. Set up the units of these timers as time. Create the PID controller as shown at Tab4.

And now the program, its quite short because the built in commands take care of the low level details.

20 OFFTIMR1 = 00:01:40 - ONTIMR1

I checked the operation of the program by switching the PID to manual mode near tab4. Type in a number for the value from 0 to 100 percent and watch the results as VAR1 goes from 0:0:0 to 0:1:40 while VAR2 does the opposite. When you’re done testing be sure to flip the PID controller back to auto.

Thanks Maurice for your answer

The difference for me is that you need 4 line of code and two global variable where I use only one line per valve with only one local variable…
What if I have 15 valves to manage like this?

My idea was to duplicate and adapt line like the line 110 or 120 fir each valve.

I agree with you for goto but I would make a difference for gosub…
I need the gosub only because there is no way to fix the cycling time of a PRG block , this would be a interesting option to define…
All basic real time PLC work like this .
Sedona has the same philosophy . You can define if a sub program is executed at each cycle or every x cycle.

You also did not answer my question, is control basic able to evaluate a Boolean logic function?

I always prefer that an output or a variable is written only one time with a Boolean equation rather than use of set / reset in different places that makes the program messy to understand and validate especially when there are no line by line debugging program tools,

The only case where I use multiple writing of the same variable is when this variable is a PN integer number corresponding to the step number of a state machine like SFC chart without parallel branch.

Then I use some logic and the end of the state machine to link the output to the state variable by comparison equation .

Like this I am sure that the logic is not depending of some disturbance that could occur and I can force the state machine in any step and having the output reflects the state I want.

I understand that for this case it is not critical, I just wanted to explain where does come from my habits to write output with comparison rather than with set/ reset or timer management .

Variables: Your program is fine, just offering something that is a little simpler and easy to understand the flow. Looking at your program briefly I am still scratching my head actually… but I admit I am a just glancing quickly through it. I like the programs to be simple to follow for the next person that has to maintain this code five years from now.

Boolean Operations: Yes, there are some bitwise operations, I don’t use myself them but they are documented in the help system I trust. You can access help from the T3000 application by hitting the F1 function key and its also available as a PDF here:

Run times: Agreed, the PLC and Sedona environments offer some advantages with deterministic timing and microsecond response times. We’ll get there eventually but for now make use those interval commands and you will be good to go for typical HVAC applications.

Thanks Maurice…
Another useful tools for debugging and helping people who watch the code later is the cross reference making a list of prg block line where one variable is written and read.
Usually this kind of tools allow to acces directly to the related code by clicking on one Line in the list to see the context.

I found in the software manual that search function exists, and even search replace ( what is very nice for avoiding coding mistakes) but probably in one program bloc only…

I hear you on the debugging features, I used to program and commission buildings myself so I know what its like out there. We’ll get you there eventually, your input will be important once we’re into this.

3 posts were split to a new topic: Integrating with codesys

3 posts were split to a new topic: General setup