I am new to Temco controllers and Control Basic. Sorry if my questions are too basic, but I would appreciate assitance
With RTD sensors (eg 10kNTC) it is possible that the connecting wiring is open or short circuit, so I would like to check for these conditions. Open Circuit (very high resistance) will appear as a very low temperature; short-circuit as a very high temperature. In my project sensors operate within a temperature band of say -10degC to +40degC (air) or +10degC to 90degC (heating circuit).
I propose to check if sensor indication is within this range to verify there are no wiring errors/faults. If there is a fault I need to ignore the faulty reading
I could use ALARM function to indicate an error, but
I managed to delete your next response here showing that you discovered the built in open and short circuit detection. Good of you to post here and discuss the feature. The input will indeed get flagged as open or short circuit and an alarm will be automatically generated. You could also add some program statements to turn on or off the equipment in the open or short conditions, you’ll need to base these on reading the extreme temperature conditions, -40F for an open circuit as shown.
Thanks. My original post was sent a bit prematurely, and was incomplete. I have now done some experiments so have some follow-up questions & observations.
Using Pt1000 sensors the indicated value when shorted is -200degC and the opencircuit value is +300degC. I see the status change on the Input table and the fault in the Alarms table.
I understand you to say I cannot base any program decision making on the NOT-Normal status or the Alarm - instead (if I think it is important enough) I must include some program logic to stop or filter-out/ignore invalid results based on the indicated value. If I dont do this, my program will still attempt to run (eg control set-point) based on the (invalid) indicated value. A filtering function might change program execution if the indicated temp below -50degC or above 100degC.
The built-in checking function seems to be aimed more at diagnosing faults than preventing strange results.
I notice there is only a short delay between the fault occurring and the invalid value being indicated on the Input table, but a very long delay before the status changes (eg to “open”).
Sounds like the alarms are working for 1k Pt sensors. The system grew up around 10k thermistor sensors so this is good news.
The delay time for an alarm to come up when I was testing this for you was about a minute, the delay is on purpose to avoid a lot of false alarms. If you need something faster acting you can write some program lines looking at the temperature itself, that will update every few seconds.
There’s a few statements related to alarms, ON-ALARM or somethign to that effect. Check through the documents and help system (F1 key from T3000). Personally I would write a few safety lines at the end of my program to cover not only the open & short condition but also anything other than nominal. Lines at the end of the program will override the lines up above so this is where the interlocks and safeties go.
I see the sense in having the delay before alarm, and the guard-rails.
One other query about alarms:
I am planning to have the controller running “dark” much of the time - ie unattended, without a laptop connected. I want to indicate an alarm has occurred to prompt a visiting “operator” to connect a laptop/screen to see what is the trouble and fix it.
What I would like to do is allocate just 1 DO (with a warning buzzer/light) to activate whenever any/all alarms activate. I can do it by allocating a variable to each individual alarm condition - but I will use a lot of variables that way. Is there any way to trigger the DO just from recognising an älarm state, ie “some kind of alarm has happened”??
Hi Maurice,
I have not had any response to this question, so I posted on the Forum/Outputs. This may not be the right category, but it made most sense to me.
Also I put a long post on the Forum/Input Signals & Conditioning - topic “Momentary contact switches and UI” to try to resolve my problem with momentary switches.
My preference is that the UI (in digital mode) is able to detect a momentary contact closure of say 100-200ms, and also allow software contact debouncing. The conclusion I am coming to is that these are impossible with the basic scan time of about 1sec. Use of the UI/Analog Range 45 or 55 pulse count slow/fast seems to require a repetitive pulse stream or very-slow (<1Hz) intermittent pulses.
There’s a long post about momentary contacts in the post copied below.
The gist of it is you can detect short pulses of 0.01 seconds on the high speed inputs and about 0.5 seconds on the low speed inputs. This pulse detection speed is independent of the scan time of the programs, pulse detection is done in a high speed task separate from the lower priority program task.
I missed your question above about the “DO’s”. You can accomplish what you need for a flashing light with with some separate logic, just create a timer and when it hits a certain point you do the DO logic. It would be separate from alarms though.
