On/off vs off/on & variable debugging

[chris.briend]

Hi,
getting started on my DIY home HVAC project, and trying to tie all my components together using a T3-TB, it’s only hooked to power and ethernet for now as I’m trying to figure out how best to use it.
Trying to run a simple program, but it is not behaving as expected, and I can’t find a way to debug it.
I’m wondering if there isn’t a couple of fundamentals I’m missing. (I do have a strong programming background, but much less hvac/electrical experience)

The test program I wrote was just to test boolean transitivity from input to variables, to outputs.
So let’s say I have HEAT_CALL an input, TVAR1 an intermediary (global) variable, and HEAT_LNK an output.
I want to have TVAR1 and HEAT_LNK to be true when HEAT_CALL is true, and false otherwise.

one way to achieve such a thing is to do something along the lines of:
20 IF HEAT_CAL THEN TVAR1 = 1 ELSE TVAR1 = 0
30 IF TVAR1 THEN HEAT_LNK = 1 ELSE HEAT_LNK = 0

or a shortened version:
20 TVAR1 = HEAT_CAL
30 HEAT_LNK = TVAR1

based on the led display of the device, and manually setting the input, the behaviour I’m expecting is to have the input light up at the same time as the output, but I’m getting the opposite…

1 - I initially thought this could come from the on/off vs off/on selection of units, as for custom units it seems that we can inverse the led display, but in my tests selecting on/off vs off/on for any combination of input/variable/outputs had no effect on the final bevahiour…
I’m starting to think this distinction might just apply at the electrical level (ie, open/close circuit for input or 0/13v output voltage), and that from a programming standpoint the boolean values are not inverted, and the led always will behave the same no matter the ordering, but would love to get a bit of clarification on it, as in that case the distinction doesn’t make sense to me for variables… Also I initially thoughts outputs were dry contacts I could directly use directly in a 24vac circuit, but looks like they actually provide either 0 or 13vdc ? what’s my best option to turn it into dry contacts? I could use an additional multi channel relay board, but if there is some sort of add on it would keep things more compact and tidy.

2 - Back to the initial “bug”: Digging a bit more into it for this post, the surprising boolean logic behaviour seems to come from some sort of caching issue for global variables: if I use a temporary variable instead of a global one, then the program works as expected. Is this a bug or an important distinction between local and global variables I need to understand?
Also, what’s the best way to “debug” variables? the state change doesn’t appear in the variable table as far as I can tell when a manual change is triggered. Would setting up graphics allow me to see those changes in close to real time ? (same question for outputs).

3- since I’m here, can I ask for more details on the WAIT instruction ? The doc mention that outputs are actually effective until the program exits it’s current iteration, but looking at the WAIT example in the doc, I assume that outputs are actually written to, and relay switched while the program is waiting… is that indeed the case? how does that affect the behaviour of variables ? is there any other instructions/commands that results in the outputs being flushed?

Thank you,
Chris

[maurice]

INPUT LOGIC:
The usual input setup assumes you have a dry contact and use the first choice there, with the range set to OFF - ON. In this mode the open circuit corresponds to OFF and the opposite for ON.

Then your two example programs there work as you said, the vars and modes just follow the input.
20 IF HEAT_CAL THEN TVAR1 = 1 ELSE TVAR1 = 0
20 TVAR1 = HEAT_CAL
And yet another method is
20 IF HEAT_CAL THEN START TVAR1 ELSE STOP TVAR1

To get the LED to behave as you’re expecting you will need to reverse the logic on the input. I’d test this our but as far as I know the programs dont have to change.

OUTPUTS:
There’s two types of outputs on the T3 controllers, the analog and the digital. You can see what type of hardware you have here at Tab1, in my example I am offline with no device so it shows virtual (VD) here at Tab2. When you are connected to live hardware you will see DIGITAL or ANALOG at Tab1 depending on the hardware for that particular output:

One thing I will point out is that an analog output can be configured as a binary output if you need some extra DO’s. For OFF the analog output will go to zero volts and ON it will be at 10V or so. This can be wired to a relay to convert an analog to a relay output. Search the web store for the AO2BO relay outputs for this purpose or you can wire in any low energy 12VDC coil relay. The AOs can power about 100ma @ 10V which is enough for the smaller relays.

DEBUGGING VARS and PROGRAMS:
The best way to debug your program is to set up a display with all the IO and vars related to this program. Toggle the outputs and inputs to manual mode and watch what happens to the rest of the elements on the display. Also setting up a trend log for all items is helpful. Set the log to a few seconds when debugging and later bump it up to 5 minutes for long term logging.

LOCAL VERSUS GLOBAL VARS:
You mention differences between the global and local vars, they should behave the same as far as I know, keep in mind there may be a few seconds delays as the logic does its thing and changes propogate. The only difference is you can use global vars on a display, on a trend log and in other programs so they are useful at this debugging stage. If you are running out of vars you can switch them over to local vars later.

WAIT STATEMENTS AND OUTPUTS
I will have to check with the team but my understanding and all our documents mention the outputs refresh when the program logic exits, at the end of the program. For this reason the way I encourage people to program is to let the program run its course every single scan. Dont use the gotos to create infinite loops or there will be problems. And waits, as far as I know they would hold up the program but sounds like you are saying that’s not the case, I can have the team check into this. My suggestion in general is to use timers rather than waits, its easier to debug since you can put them on the displays and trend logs.
10 VAR1 = TIME-OFF( OUT1 )
20 VAR2 = TIME-ON( OUT1 )
30 IF VAR1 > TIMEFLAG THEN START OUT1
40 IF VAR2 >TIMEFLAG THEN STOP OUT1

Make sure VAR1, VAR2 and TIMEFLAG (VAR3) are in the units of TIME, not seconds, minutes, etc. This makes it easy to do math and logic using time. There’s no wait statements required.

[chris.briend]

Thanks for the detailed explanation, Maurice. it didn’t solve my issue, but did help grasping a few things.

I did solve my issue though: My global variable was using “on/off” as a unit, to match the input and output units.
If using “unused” instead, it works!
“unused” sounds like the variable is unused, but it looks like it just means unitless. Which is also probably the default state for temporary variables.

This still feels like a bug to me though.

There are a few other bugs I encountered while trying to debug:
The trend log is barely functional for debugging, as it doesn’t update at a reliable or fast enough interval (10-20 seconds, even with the interval set between 1 and 5 seconds in my test). it also forget data points in the middle of a graph, and some updates seems to only update a subset of the trend points.
The graphics are worst, not usable. Opening them gives me an unauthorized access error, followed usually by a crash… (100% crash if I double click “element count”)

One thing I asked about was if the output were dry contacts… I tested the digital ones, and they are, I’m able to activate the 24vac valve with them… They do open/close differently depending if the output is set to on/off vs off/on like you mentionned.

This however seems to contradict the documentation…
Here is an excerpt from 6.4 Ouputs - range section:

The following digital output ranges are available (select 1 for Off/On, or 12 for On/Off):
1/12 Off/On 2/13 Close/Open 3/14 Stop/Start 4/15 Dis/Enable
5/16 Norm/Alarm 6/17 Norm/High 7/18 Norm/Low 8/19 No/Yes
9/20 Cool/Heat 10/21 Un/Occupied 11/22 Low/High

Select the range according to the following convention: the state on the right side of
the slash (/) is has a value of 0 Vdc, and on the right side of the slash the value is
13 V dc (0 Vdc/13 V dc). Only when the output is 13 V dc the LED will turn on

As a recommendation: use normally closed relays if the equipment need to be operational
in case of a power failure. Then select digital output 12 (On/Off). When the equipment
is commanded to turn off, the volt age will be 13 V dc , opening the electrical
circuit, thus turning the equipment off.

Can you please confirm I can safely use the digital output as dry contacts (with up to 2A 24Vac, as per the brochure) ? I’d highly recommend updating the documentation if that’s the case…

[maurice]

Haven’t run into this ‘on-off, off-on, local global variable’ issue before as an issue but we’re always on the lookout for quirks, Lijun will study the thread and report back here.

On the trend logs screen updates and the graphics, you should update your T3000 as our team has done work lately on both these items. Trend logs could be sped up more for the debugging, we can work on that. Personally I do most of my debugging in a text mode graphics UI, add all the IO and vars to a display with no graphics. You can also place an icon to pop back and forth into the programming from this display. Hit the refresh button at Tab2 to speed up the refresh.

The relay outputs are indeed dry contacts and the analog outputs are 0-10V analog. The only thing that might not be clear is that the analog outputs can be set to work in a binary fashion, they will still be analog outputs but with only 0V and 10V states. You can see which type of hardware for each output in the ‘Type’ column at Tab1.

[chris.briend]

Hi Maurice,
my T3000 is using the latest version (august 9 2024), so maybe that’s a new bug ?

Happy to help with anything you need to get the graphics to work, but I can’t find any useful logs to send.
After the initial connection issue, if I try to show the graph again, it just crashes the app…
I spend 2hrs last night trying to debug using the trend graph, but it’s just too painful and unreliable to use. (see blue and green graph bellow)
Also noticed that it doesn’t support more than a few binary variables at once, as it draws them under the other ones in a fixed size window pane… I have to disable the top ones to see the bottom ones.

TBH I think the old school trend logs UI is beyond saving… Since you already have an embedded browser window, if you are able to dynamically export your data to some standard format such as CSV, then it would be semi-trivial to display the data via something like the google charts js lib. There are a bazillion freelance web devs out there that would do it for just a few dollars.

[maurice]

These trend logs is an area I know that can be improved in our system. Our crew will study your notes & screen shot and see what we can do. Also the CSV export and sync with google etc has been on the drawing board for far too long, we’ll work something out.