In Lookout, how can I make the equivalent of a "4 changes per day" set-back thermostat?

[JW_Tech]

Ok... I need some help here....

I have a Pot_TSP (Temperature setpoint) that uses a PLC register as its remote source. I added a night-time temperature setback feature by adding a "DAYTIME" expression as a permissive, and tying two new Pots (Pot_SP1 and Pot_SP2) to Pot_TSP's "reset value" :       NIF(Expression_Daytime, Pot_SP1, Pot_SP2). 

Client now wants this increased to 4 optional temp changes per day, just like a household 7-day programmable T-stat. Adding the additional conditions to the "reset" parameter was easy; one extra TimeOfDay timer for each temperature Setpoint change, arranged as "OR" functions. Each time the clock hits one of these TOD targets, Pot_TSP gets "reset" and the "reset value" gets written to it. Here's where I start to bog down... How do you arrange this so that when one of the 4 TOD targets goes "true", its corresponding SP value gets written to Pot_TSP? The closest I've been able to get is this: make a new Pot (Pot_X) with a min of 1 and a max of 4 and use a NCHOOSE to select which of the 4 Temp setpoint Pots Pot_X will use as the (next) SP. If I rotate Pot_X and the clock hits a TOD target, a value corresponding to the selected Pot gets written to Pot_TSP. 

So can someone please tell me how to get Pot_X to align itself with the TOD events? I can get a limping model if I slave the NCHOOSE function to a Counter object, but if the customer has Lookout turned off or disconnected long enough to miss one of the events, Pot_X will go out of sync. Same goes for incrementing the Pot object. Can't allow that...

Since the clock never stops and only hits each TOD once every 24 hours, there would never be more than one of the 4 TOD conditions true at one time... is there a way to build an expression object (or the like) to ultimately produce a numeric (the Pot_TSP value) using the following logic: If TOD1 is true, return Pot_SP_1;  If TOD2 is true, return Pot_SP_2, If TOD3 is true, return Pot_SP_3; If TOD4 is true, return Pot_SP_4   ????

Thanks guys.

G

[JW_Tech]

Belay that request...

The obvious answer WAS the right one (I just hadn't ever needed to write the code before); nested IF functions. OK that gets me my 4 Temperature Setpoint changes for that one day. Now to make a "7-day" program, the "day" logical objects are "Time of week" timers with 0-6 day offsets(?).

Conveyed the good news to the boss; boss now wants same functionality added to the 3 other variables in the zone: Humidity SP, Pressure SP, and Flow SP. (See? Never a carrot; always the STICK!).

So that's a possible 16 programmed SP changes per day per zone. Times 4 zones per control panel, times 7 days = 448 fields (numeric SP entry) I need per panel. And some places have up to 7 panels.... can any of you guys give me some guidance and/or good examples using Data Table object(s) for this (or any other options you can think of) for this application?

Cheers

G

[Ryan.S]

16*4*7, it looks like a 3-d array, but the datatable is 2d. So, you can assign one datatable for each zone.

The row can be each day, and the column stores the 16 changes data. The datatable's cursor is helpful to switch the row.

For example,

Pot1 = datatable.A.1

When the datatable.cursor.1 = 1, Pot1 = datatable.A1

When the datatable.cursor.1 = 2, Pot1 = datatable.A2

In this way, you can easily change the pot1's input from different row by controlling the cursor. 

This is a simple example of the datatable

http://zone.ni.com/devzone/cda/epd/p/id/4083

You can also take a look at the example batch2.l4p from Lookout Folder\Examples\Applications\

[JW_Tech]

Thanks (as always!) Ryan,

Took a look at the example in the link you provided. It solved some of my problems, but  also created more questions...

The position of "Cursor1" is the vaue of "Pot_cusor", whose remote position source is the expression

nif(exact(DataTable.a.txt,"Site1"),1,nif(exact(DataTable.a.txt,"Site2"),2,nif(exact(DataTable.a.txt,"Site3"),3,Pot_cursor)))

Can you shed some light on why this is written this way? Does it NEED to be? Why the use of the "exact" function?

Next: The examples describe how to import/export to Excel. Is the documentation for the Lookout Development Manual and "Help" library accurate? Specifically, if I want to import/export the DataTable to an Excel spreadsheet file, does the version of Excel still have to be 4.0 or less? Is there a workaround so I can use a recent spreadsheet app, or some other way to emulate this? (Ver 4.0 went obsolete in what, 1993?)

Thanks,

G
 

[Ryan.S]

The datatable's datamember 1, 2 or 3 are connected to the Pb_Sitex

If 1 is true, cursor.1 = 1

if 2 is true, cursor.1 = 2

Okay, it seems an undocumented datamember.

cursor.1 = Pot_cursor, so you can control the pot to change cursor.1

When cursor.1 changes, DataTable.a.txt changes between "Site1", "Site2" and "Site3".

When the Datatable.a.txt changes, it triggers the expression

nif(exact(DataTable.a.txt,"Site1"),1,nif(exact(DataTable.a.txt,"Site2"),2,nif(exact(DataTable.a.txt,"Site3"),3,Pot_cursor)))

This expression compares the Datatable.a.txt with the word to find the site number. The site number is sent to the pot_cursor.

So, it is a loop chain.

Whenever you change the cursor by clicking the button under the red graphic, the pot_cursor changes accordingly.

Whenever you change pot_cursor, the datatable's cursor changes accordingly.

Whenever you click the Pb_SiteX, the datatable's cursor changes and then the pot_cursor changes.

What's your lookout version? We added the support for 2003 format in 6.5. Excel 2007 uses a different type of file(.xlsx instead of .xls), we may add this support in the future.

If you don't have 6.5, you may not use Excel 2007 since it cannot save file as 4.0 format. Excel 2003 or lower can save file as 4.0 format.

To use Excel 2007 or higher with 6.5, you need to save the file as 2003 format.

[JW_Tech]

Hi Ryan

Thanks again for your input! I'm more comfortable with the DataTable object (now that it's become more familiar), and thanks to you I now have a DataTable constructed for one zone (7 rows for the days-of-the-week, and 16 columns for the variables). Displaying of the cell data, cursor navigation, and reading/writing to the Pots' remote position source (in other words the actual GUI) work just fine. In order to expedite completion of the project for which this DataTable is intended, I am at a point where I am prepared to clone the DataTable 3 times to get 4 zones (that's one panel), then clone that result times the number of panels the site has....but I'd like to run this by you first:

Unless it's contrary to "best practices", should I do as above, or try to further multiplex the DataTable I already have by adding to it the other three zones? The Table I have now serves one zone; can it be expanded to serve (dare I suggest it) one panel (4 zones)? If you recall, I started out thinking I'd need one dedicated Pot for each variable in each zone (16) times 7 days = 96; using the DataTable, the cursor replaced the d-o-t-w so the number of Pots needed dropped to 16. My point: if I have to make separate DataTable objects for each zone, I also need to make 48 more Pots to serve them (which I'm obviously trying to avoid). Then I have to repeat this times the number of panels on site. I'm guessing that adding 3 more zones to the existing (one zone) DataTable is no problem since there's plenty of room left... 

But would you add them as columns (to keep the cursor consistent across the zones) or add them as rows (to keep the columns consistent across the zones)? 

If added as columns, can I avoid making those extra 48 Pots? Can I make my existing 16 Pots read/write to multiple columns, like change the Remote Source for Pot_Temp_SP_1 from "..\DataTable.B" to something like "nchoose(Pot_Zone_Selector,..\DataTable.B,..\DataTable.R)" where columns B and R contain Temperature setpoint values for Zones 1 and 2 respectively?

If added as rows, I'm guessing I don't have to make those extra 48 Pots. But what's the best way to deal with the cursor? Should I be looking at multiple cursors (one for each zone)?

I should also point out I've been using only L3 Pots since "normal" Pots won't accept an expression as a remote position source; if I change this to regular Pots coupled with SymbolicLinks, does it change the picture at all?

...and I'm using Ver 6.0.2

Thanks,

George

[Ryan.S]

Of course you can use just one table for multiple zones.

I'm not sure if you know there are two kinds of connections. Assume you have a "normal" pot. On its property dialog box, select "Remote", you can input a connection to a datatable cell in the green field. The green connection is a two-way connection, which means when the pot changes the datatable cell will change, and when the datatable cell changes the pot will also change.

In Object Explorer, right click on datatable and select Edit Connections..., select a writable datamember, and input the expression in the yellow field. For example, you connection Table.A1 = Pot1, it means when Pot1 value changes, A1 will get the value. But if A1 changes, Pot1 will not get it.

So, if you just need the pot to write data to datatable, but don't need the datatable write data back to the pot, you can create the second connection on multiple datatable cells. Such as

Table.A1 = Pot1

Table.A2 = Pot1

....

You'd better not use the L3 Pots.

[Ryan.S]

It looks like you do need to read data from datatable to pot... Let me think about it...

[jbesselm]

Would a time clock or scheduler similar to the one depicted in the attached graphic work. Instead of each "channel" of the time clock controlling a piece of equipment the channel would select a pot that contains the desired set point. The process we use for this is built with a sequencer object and we have deployed it in many of our installations. The sequencer synchronizes itself to the PC clock. This might be a crude brute force approach but it's simple and doesn't use much i/o in our case only one word.