There are a few enhancements I would really appreciate seeing in T3000…
-
Ability to export Inputs/Outputs/Variable tables in a form readable by Excel. Without this I have to maintain a separate list in Excel which is hard to keep synchronized.
-
Refresh during Program editing: The current AUTO-refresh/compile while editing a program is a real nuisance! The auto-refresh ALWAYS comes at the wrong time. If it happens part way through a copy-paste edit it introduces errors. It always recasts the screen so I have to re-find my insertion point. When I have just completed editing a new line (ie when it would be useful), auto-refresh it never seems to happen!
It would be much better to have a click-button for “refresh now”
-
TIME-ON ( ) and TIME-OFF ( ) do not evaluate if the expression is Analog The expression in brackets must be binary.
10 IF TIME-ON (IN2 < 5) > 0:00:10 THEN START OUT1 does not work if IN2 is analog.
It would be good if the “error-reporting” system would trap illegal use of analog expressions. (it would be even better if analog expressions which have binary outputs were legal for TIME-ON etc
1 Like
Excel: The entire prog contents (all io, vars, programming, graphics, etc) are actually stored in a microsoft ‘Access’ format DB, I will have the team write that up along with some tips on how to work with excell.
Refresh: Our team will fix that asap.
Time-on: I am not fully following the question there, but one suggestion is to create a variable in teh units of time,
10 VAR1 = TIME-ON( IN1 )
20 IF VAR1 > 0:0:10 THEN START OUT1
This way you can put a trend log on the timer, place it on displays and so on. Its much easier to debug a program when everything is brought out in the open as a global var.
Ref TIME-ON(), _OFF() functions - yes, there are various work arounds. My point is that, because it is invalid to include analog variables in the expression, this should be flagged as an error when compiling, rather than compiling a function that will not work.
OK, we will add a warning to set the range to the units of time during compile. Its a good idea.
I have not explained the issue properly. The problem I have stumbled into is, for example, in writing:
20 IF TIME-ON ( AIRTEMP > 20 ) > 0:0:10 THEN START FAN1
Where AIRTEMP is an analog variable with units of degC
Although (AIRTEMP > 20) has a true/false result, the TIME-ON function will not evaluate the logical test, so that line will not work. Currently, to make it work, I need to write:
20 IF AIRTEMP > 20 THEN TEMPTEST = 1 ELSE TEMPTEST = 0
30 IF TIME-ON ( TEMPTEST ) > 0:0:10 THEN START FAN1
where TEMPTEST is a binary Off/On variable.
I was suggesting that (either) the pre-compile error-check looks for and reports a syntax error in line 20 (because there is an analog variable within the TIME-ON expression, which is invalid), (or) arrange that the TIME-ON function does evaluate the logical expression.
Just make a variable for the timeon of the situation. Cramming it all into one line is maybe efficient but not maintainable. Create a variable, monitor and log the condition, put it on displays, alarm it as appropriate. Good to go.