graphing constants

[brnlow]

I am trying to make a temperature graph that shows a set point temperature and current temp. I am using an edit box to allow the user to designate the set point. The edit box sets the channel V.setpoint upon button press and the current temp (channel Tprobe) is read every second.

In my graph, traces/y expression are set to Tprobe and v.setpoint with x expression set to time.

I get a great graph of the current temperature from Tprobe, but v.setpoint is only graphed/updated when the edit box button is pressed and does not graph the virtual channel as a function of time. For example if at time = 10 min v.setpoint is 50 and at time = 20 min v.setpoint = 100 what IS GRAPHED is a diagonal line from 10 to 20 min instead of a 50 degree step at time 20min.

How can I make the graph keep displaying the setpoint value between edit box submit actions? I would like to have a step function graph.

Thanks

Bill

[AzeoTech]

First, please read the blog post about why you should not use edit boxes in main page displays. It is here:

http://www.azeotech.com/board/index.php?showtopic=3233

OK, now on to your question. As you saw, outputs only get values when they are actually set. Since the graph is really an XY graph, but with time in the X, it doesn't do well with widely spaced outputs. To get around this, you need to use a channel with history to store the output value for each interval (usually matched with some input). To do this:

1) have the edit box (or whatever input type you change to once you read the blog ) change a global variable instead of a V channel. Call the global "setpoint" if you'd like. You'll need to declare it in a sequence marked AutoStart by doing: global setpoint = 0 replacing 0 with whatever the default should be.

2) in the Event for the Tprobe channel (click on Tprobe in the workspace, then select the Event tag), put:

V.setpoint = setpoint

3) now you can graph v.setpoint as it will have a history of setpoint settings for each TProbe input reading (provided the history is long enough).

[brnlow]

Hi,

Thanks for the information and and the food for thought about the edit box - since I am the only user (hobby/toy) I don't think the edit box issue(s) in the blog will apply.

I was playing around with your suggestion and still can not get the graph to work. If I pull up the v.setpoint channel table, I can watch the table being updated every sec by the Tprobe channel event, however the graph only updates when the button is pressed and ignores the values of v.setpoint history.

Any other suggestions?

Thanks

Bill

[AzeoTech]

Can you post what you have? Did you graph v.setpoint or setpoint? It must be V.Setpoint in the graph expression.

[brnlow]

Appears that I've got it working:

Auto-Start Sequence "declare_variables" :

V.setpoint.ClearHistory()

global setpoint

global heater_on = 0

global heater_off = 1

Channel Tprobe Event:

setpoint.time = systime()

V.setpoint = setpoint

When I read your last post it got me to look at what was really being updated and I noticed that the V.SetPoint channel table was updating every second, but the time value was staying constant. Setting setpoint.time = systime() has got the look of the graph just as I want it.

I remember reading that DaqFactory time is not necessarily the computer system time, will this cause any major problems?

[AzeoTech]

Not really. Usually it will only drift very slightly if at all. On some machines, usually ones that have been overclocked or other major mods they drift quite rapidly, even a second every second. In this case you would probably need to use the usertime.dll file that is located here. This will cause DF to use the system clock, however this can actually cause some major problems (and why we don't default to the system clock):

1) it is not nearly as precise as the clock we use. Last time we checked it was precise to 15ms max.

2) any changes to the system clock (such as DST) can cause sequences and other things in DF to glitch. For example, in the fall, when time is set back by an hour, all channels would stop acquiring for 1 hour waiting for the time to get back on track. Worse, if you have alarms or other things that are looking at deltaT values (such as timeouts), these alarms would trigger. If you use the wait() function and possibly other functions, you could even cause DF to hang unless you design your system appropriately.