DLO6 - Timer Woes
- Thread starter DL06
- Start date
Terry Woods
Member
- Join Date
- Apr 2002
- Posts
- 3,170
"Actually binding the Vmem makes it much simpler to program. How much extra time and more complex would it be if you had to assign memory for each timer?? Quite a bit. Additionally if you dont use the timer; for example timer T21, then V21 would be available as user memory. So it's only dedicated if your using that timer."
Why would referencing a V-Mem location be any easier and less complex than referencing a Timer location? There is absolutely no difference in the effort required.
Nothing I spoke of even suggested that a programmer had to assign memory locations for Timers. To reference a timer by "type" automatically allocates the appropriate amount of memory... just as in AD, except there is no possibility of "stepping" on another timer. And, all timer references are available unless explicitly used. No matter how you use T1, T2 is available until you use it.
So... even though it is available, you don't use T21. However, you end up using V21 for something. Now, T21 is not available. And, if T19 is already being used as a Standard Timer... then T20 can only be used as a Standard Timer.
This scheme is reminiscent of the days when all logic had to be run through a minimization procedure because there was simply not enough logic available.
"It's entirely possable that a program might require two references, or more then one timer using the same timer reference. Your "Smart" package would preclude that possability. I've done many application where "stepping" on a particular Vmem location was intentional."
The "smart" package timer allows constant values or V-mem references for Preset values. V-xxx can be used by any number of timers. Nothing is precluded in that respect. As far as Accumulated values, any instruction that "writes" can write to any Accumulated value. Again, nothing is precluded. Any instruction that "reads" can access the Preset or Accumulated values of any timer by simply referencing the timer. You don't have to remember which V-Mems might be associated with a particular Timer.
"Stepping" is the act (usually unintentional) of crossing a boundary... as in stepping on someone's toes. If a valid double-word exists at V100/V101, and then, you write a double-word to V99... you would be "stepping" on V100.
For a given double-word at V100/V101, having a legitimate reason to write a single word to V100 -or- V101 would not be "stepping".
In AD, if you use T1 as an Accumulating Timer, and then you try to use T2 as either a Standard Timer or an Accumulating Timer, T2 would be "stepping" on T1... not good. The AD method allows this "stepping" to occur.
In a free-range, or open, memory system, where you are not restricted as to how you use the V-mem (as is the case with Integer-Files, Real-Files, etc.) the programmer must, of course, be mindful of his data-types and where they reside. It is very easy to "step" on data if one isn't careful. But this simply shouldn't be the case for Timers and Counters.
The only difference between a Timer and a Counter is the manner in which the accumulated value is updated. In timers the accumulated value is updated on a time-basis. In counters, the accumulated value is updated on an event-basis. Aside from that there is no difference.
In TI, all timers and counters are maintained in the same memory area. They belong to the element group called T/C (Timer/Counter). As such, you assign the reference numbers from the pool of T/C numbers, like so...
.
All of the timers (TMR & TMRF) and counters use only 2 words. One word is for the Preset value. The other word is for the Accumulated, or Current value. All values are maintained in Binary-Decimal... not BCD. The range of the counters and timers is as follows:
CTR: 00000 to 32767
TMR: 0000.0 sec to 3276.7 sec (tenth-second time-base)
TMRF: 00.000 sec to 32.767 sec (milli-second time-base)
Notice that the ranges are numerically the same except for the positions of the decimal points.
The actual value in the preset location and the accumulated location, in all of those, ranges from 00000 to 32767. The decimal point is "virtual", and it is determined by the T/C-type. For counters, there is no decimal point. For TMR, the decimal point "exists virtually" at the tenth-second location. For TMRF, the decimal point "exists virtually" at the milli-second location.
Simply declaring the timer-type tells the timer what time-base to use. If you want to use a time-base other than tenth-second or millisecond, then create a timer that is preset to that time-base and use the output from that timer to increment, or decrement, a counter. Since the counter is now driven by a time-base, the counter now becomes a timer. (Timers and Counters are the same... except for the nature of the trigger.)
Preset values can be explicitly assigned with a constant value when the T/C is created, or they can be assigned dynamically by means of a V-Mem reference.
.
Some PLCs update their timers and counters from the Preset value towards 0, while others update from 0 towards the Preset value. Regardless, the Accumulated (Current) values are initialized when the T/C is first scanned. After that point, the Current value can be accessed at any time simply by referring to the current value reference of the particular T/C.
If you want to "read" from, or "write" to, the Preset value, or the Current value, of T/C-3, you simply reference TCP-3 and TCC-3, respectively.
.
If you want to perform math operations with an accumulated (current) value, you simply need to know what that value represents; integers, tenth-seconds, milli-seconds, or custom. You then have to design your math to accomodate the particular type.
For example, using a basic ADD Instruction... TCC-1 + V105 = TCP-4. Is that complex?
All of this happens without having one timer/counter accidently "stepping" on another timer/counter just because you didn't remember the type of a particular timer. This method precludes that from happening.
"...but after doing hundreds of applications with AD PLCs, I can see the logic in it."
Well, of course you can. It is "logical". However, it is "logical" only in the sense that it works; in the same way that logic, extensively reduced by a K-Map, works... but is it user-friendly? Clearly, it is not.
Mike, you have simply come to terms with AD being as it is. Does that make it good?
"If it ain't broke, don't fix it." <<== That... is a matter of perception!
Eric said...
"Sorry Terry, but this 'idiocy' has never caused me any grief. DirestSOFT is just soooooo intuitive to use...
On the other hand, GE's use of 3 registers for a timers HAS aggravated me. Who counts comfortably by 3?..."
Since when is having to manage Timer Memory more intuitive than not having to do so?
Regarding GE, at the least, you can always know that GE uses 3 words to maintain their timers; not one, or perhaps two.
As I recall from my days with Logicmaster, the timer/counter registers were, and I assume, still are, drawn from the general V-Mem pool (%R). This certainly was a pain in the neck... until I figured out that, since GE Timers ALWAYS used 3 words. It was quite beneficial to use Base-3 math to manage Timer/Counter addressing. Don't choke on it... it really ain't that bad!
I would set aside a region of memory just for timers and counters. It would always be prudent to put aside twice as much as one would anticipate needing. I would generally put aside the area between %R-1000 to %R-1999. That would be enough for 334 Timers and/or Counters starting at T/C-0.
Then, "knowing" that Timer/Counter addresses are based on the Timer/Counter BASE-ADDRESS Number (%R-1000) and subsequent Timer/Counter addresses specified in Base-3, relative to %R-1000, the addresses become apparent.
It was an extra step, but you ALWAYS knew that the locations were available.
That is more reasonable than trying to manage Timer/Counter Memory locations that might, or might not, be available.
Why would referencing a V-Mem location be any easier and less complex than referencing a Timer location? There is absolutely no difference in the effort required.
Nothing I spoke of even suggested that a programmer had to assign memory locations for Timers. To reference a timer by "type" automatically allocates the appropriate amount of memory... just as in AD, except there is no possibility of "stepping" on another timer. And, all timer references are available unless explicitly used. No matter how you use T1, T2 is available until you use it.
So... even though it is available, you don't use T21. However, you end up using V21 for something. Now, T21 is not available. And, if T19 is already being used as a Standard Timer... then T20 can only be used as a Standard Timer.
This scheme is reminiscent of the days when all logic had to be run through a minimization procedure because there was simply not enough logic available.
"It's entirely possable that a program might require two references, or more then one timer using the same timer reference. Your "Smart" package would preclude that possability. I've done many application where "stepping" on a particular Vmem location was intentional."
The "smart" package timer allows constant values or V-mem references for Preset values. V-xxx can be used by any number of timers. Nothing is precluded in that respect. As far as Accumulated values, any instruction that "writes" can write to any Accumulated value. Again, nothing is precluded. Any instruction that "reads" can access the Preset or Accumulated values of any timer by simply referencing the timer. You don't have to remember which V-Mems might be associated with a particular Timer.
"Stepping" is the act (usually unintentional) of crossing a boundary... as in stepping on someone's toes. If a valid double-word exists at V100/V101, and then, you write a double-word to V99... you would be "stepping" on V100.
For a given double-word at V100/V101, having a legitimate reason to write a single word to V100 -or- V101 would not be "stepping".
In AD, if you use T1 as an Accumulating Timer, and then you try to use T2 as either a Standard Timer or an Accumulating Timer, T2 would be "stepping" on T1... not good. The AD method allows this "stepping" to occur.
In a free-range, or open, memory system, where you are not restricted as to how you use the V-mem (as is the case with Integer-Files, Real-Files, etc.) the programmer must, of course, be mindful of his data-types and where they reside. It is very easy to "step" on data if one isn't careful. But this simply shouldn't be the case for Timers and Counters.
The only difference between a Timer and a Counter is the manner in which the accumulated value is updated. In timers the accumulated value is updated on a time-basis. In counters, the accumulated value is updated on an event-basis. Aside from that there is no difference.
In TI, all timers and counters are maintained in the same memory area. They belong to the element group called T/C (Timer/Counter). As such, you assign the reference numbers from the pool of T/C numbers, like so...
T/C
Ref # Usage
1 TMRF
2 CTR
3 TMR
4 TMRF
5 CTR
.
All of the timers (TMR & TMRF) and counters use only 2 words. One word is for the Preset value. The other word is for the Accumulated, or Current value. All values are maintained in Binary-Decimal... not BCD. The range of the counters and timers is as follows:
CTR: 00000 to 32767
TMR: 0000.0 sec to 3276.7 sec (tenth-second time-base)
TMRF: 00.000 sec to 32.767 sec (milli-second time-base)
Notice that the ranges are numerically the same except for the positions of the decimal points.
The actual value in the preset location and the accumulated location, in all of those, ranges from 00000 to 32767. The decimal point is "virtual", and it is determined by the T/C-type. For counters, there is no decimal point. For TMR, the decimal point "exists virtually" at the tenth-second location. For TMRF, the decimal point "exists virtually" at the milli-second location.
Simply declaring the timer-type tells the timer what time-base to use. If you want to use a time-base other than tenth-second or millisecond, then create a timer that is preset to that time-base and use the output from that timer to increment, or decrement, a counter. Since the counter is now driven by a time-base, the counter now becomes a timer. (Timers and Counters are the same... except for the nature of the trigger.)
Preset values can be explicitly assigned with a constant value when the T/C is created, or they can be assigned dynamically by means of a V-Mem reference.
T/C
Ref # Usage Preset Used as...
1 TMRF 32000 32.000
2 CTR 500 500
3 TMR 32000 3200.0
4 TMRF V100 V100 value read in milli-seconds
5 CTR V200 V200 value read as an integer
.
Some PLCs update their timers and counters from the Preset value towards 0, while others update from 0 towards the Preset value. Regardless, the Accumulated (Current) values are initialized when the T/C is first scanned. After that point, the Current value can be accessed at any time simply by referring to the current value reference of the particular T/C.
If you want to "read" from, or "write" to, the Preset value, or the Current value, of T/C-3, you simply reference TCP-3 and TCC-3, respectively.
T/C Preset Current
Ref # Usage (TCP) (TCC)
1 TMRF TCP-1 TCC-1
2 CTR TCP-2 TCC-2
3 TMR TCP-3 TCC-3
4 TMRF TCP-4 TCC-4
5 CTR TCP-5 TCC-5
.
If you want to perform math operations with an accumulated (current) value, you simply need to know what that value represents; integers, tenth-seconds, milli-seconds, or custom. You then have to design your math to accomodate the particular type.
For example, using a basic ADD Instruction... TCC-1 + V105 = TCP-4. Is that complex?
All of this happens without having one timer/counter accidently "stepping" on another timer/counter just because you didn't remember the type of a particular timer. This method precludes that from happening.
"...but after doing hundreds of applications with AD PLCs, I can see the logic in it."
Well, of course you can. It is "logical". However, it is "logical" only in the sense that it works; in the same way that logic, extensively reduced by a K-Map, works... but is it user-friendly? Clearly, it is not.
Mike, you have simply come to terms with AD being as it is. Does that make it good?
"If it ain't broke, don't fix it." <<== That... is a matter of perception!
Eric said...
"Sorry Terry, but this 'idiocy' has never caused me any grief. DirestSOFT is just soooooo intuitive to use...
On the other hand, GE's use of 3 registers for a timers HAS aggravated me. Who counts comfortably by 3?..."
Since when is having to manage Timer Memory more intuitive than not having to do so?
Regarding GE, at the least, you can always know that GE uses 3 words to maintain their timers; not one, or perhaps two.
As I recall from my days with Logicmaster, the timer/counter registers were, and I assume, still are, drawn from the general V-Mem pool (%R). This certainly was a pain in the neck... until I figured out that, since GE Timers ALWAYS used 3 words. It was quite beneficial to use Base-3 math to manage Timer/Counter addressing. Don't choke on it... it really ain't that bad!
I would set aside a region of memory just for timers and counters. It would always be prudent to put aside twice as much as one would anticipate needing. I would generally put aside the area between %R-1000 to %R-1999. That would be enough for 334 Timers and/or Counters starting at T/C-0.
Then, "knowing" that Timer/Counter addresses are based on the Timer/Counter BASE-ADDRESS Number (%R-1000) and subsequent Timer/Counter addresses specified in Base-3, relative to %R-1000, the addresses become apparent.
It was an extra step, but you ALWAYS knew that the locations were available.
That is more reasonable than trying to manage Timer/Counter Memory locations that might, or might not, be available.
elevmike
Member
Mike, you have simply come to terms with AD being as it is. Does that make it good?
Well actually yes. Overall I look at it this way. Overall it's a very good product at a reasonable cost, backed up with superior "right now" support.
Sure there's a few idiosyncracies, (as with any brand of anything), but after understanding how it goes (which happens very quickly in this case), it's no longer an issue. I can tell you about a LOT of funny things I had to re-train my self about AD (like the octal numbering), but in the end it proved to be well worth it. I'm not ready to though out the baby with the bath water.
Terry, I know nothing about AB, but have used GE- LogicMaster & CME, Omron LSS, Idec, DirectSoft and a few others. Out of them all DirectSoft was by far the quickest to pick up and run with.
On the AD forum there's a thread I started some months ago called "DS5 Wish List"; it's still going strong, and with many responses from Host Eng, (developer of DS). Not one of those many many posts mentions anything about this issue, which leads me to beleive that I'm not the only one that does not precive this as a major problem. Terry, your a very valuable contrubuter here, and I appreciate that. I just think this particular ball that your carring here is a little low on air...
That remindes me, I forgot to ask for a spell checker with the comment editor.... I wonder if it's too late???
Well actually yes. Overall I look at it this way. Overall it's a very good product at a reasonable cost, backed up with superior "right now" support.
Sure there's a few idiosyncracies, (as with any brand of anything), but after understanding how it goes (which happens very quickly in this case), it's no longer an issue. I can tell you about a LOT of funny things I had to re-train my self about AD (like the octal numbering), but in the end it proved to be well worth it. I'm not ready to though out the baby with the bath water.
Terry, I know nothing about AB, but have used GE- LogicMaster & CME, Omron LSS, Idec, DirectSoft and a few others. Out of them all DirectSoft was by far the quickest to pick up and run with.
On the AD forum there's a thread I started some months ago called "DS5 Wish List"; it's still going strong, and with many responses from Host Eng, (developer of DS). Not one of those many many posts mentions anything about this issue, which leads me to beleive that I'm not the only one that does not precive this as a major problem. Terry, your a very valuable contrubuter here, and I appreciate that. I just think this particular ball that your carring here is a little low on air...
That remindes me, I forgot to ask for a spell checker with the comment editor.... I wonder if it's too late???
I have mostly used 2 products..AB Control logix with rslogix 5000 and Modicon 984 Ladder logic..I have dabbled a little with rs logix 500 but not that much..
All 3 handle things differently..You get used to it and move on..
From reading this thread (And about a million others (And yes i do try to read ALL the threads here!) i now see AD uses 2 memory spots for timers...So what..If you know it ..work with it
If this is "Idiocy" then consider..
Modicon 984 LL (Quantum)uses 1 extra address for analog outputs.. For example..a 4 channel analog output uses address 40000-40005..40000-40004 for actual outputs and 40005 for config purposes..However 984 LL for 984 series I/O (Now obsolite) only used 4..the problem?? a 984 series I/O program is supposed to be able to load into a Quantum running 984 LL..So if you upgrade..you now have to change your program becouse you may have used 40005 as a physical Analog output..(So much for load and go)
Also with modicon..certain modules are actually WIRED different with the software you use to program!!! using Momentum style I/O In Modsoft a anlog output card (If memory serves correct) is wired differenly that if you use Concept..(Modsoft is the old dos based softawre..concept is there "New" Windows based..
Or in AB using RSlogix 5000 you can duplicate a physical output..meaning you can use the same output twice in the same program..No error..no warning..Now i am sure this might be for a reson..but i can think of one..at least warn me i used the same one twice..(believe me i did it and it causes a little bit of headache...)
Oh and with 5000 you can put the output coil anywhere...why?? it just complicates matters..
In short..ALL Platforms have there drawbacks and advantages..from what i have read AD's are it takes 2 memory spots for a timer but its half the price with great "Free" suport..
AB You can duplicate address's with no warning..It cost twice as much..and if you want support..you better be ready to shell out the bucks..
Modicon..Silly differences between platforms and softawre..mega bucks..but average phone support..No contract needed..
See good and bad points for each..
All 3 handle things differently..You get used to it and move on..
From reading this thread (And about a million others (And yes i do try to read ALL the threads here!) i now see AD uses 2 memory spots for timers...So what..If you know it ..work with it
If this is "Idiocy" then consider..
Modicon 984 LL (Quantum)uses 1 extra address for analog outputs.. For example..a 4 channel analog output uses address 40000-40005..40000-40004 for actual outputs and 40005 for config purposes..However 984 LL for 984 series I/O (Now obsolite) only used 4..the problem?? a 984 series I/O program is supposed to be able to load into a Quantum running 984 LL..So if you upgrade..you now have to change your program becouse you may have used 40005 as a physical Analog output..(So much for load and go)
Also with modicon..certain modules are actually WIRED different with the software you use to program!!! using Momentum style I/O In Modsoft a anlog output card (If memory serves correct) is wired differenly that if you use Concept..(Modsoft is the old dos based softawre..concept is there "New" Windows based..
Or in AB using RSlogix 5000 you can duplicate a physical output..meaning you can use the same output twice in the same program..No error..no warning..Now i am sure this might be for a reson..but i can think of one..at least warn me i used the same one twice..(believe me i did it and it causes a little bit of headache...)
Oh and with 5000 you can put the output coil anywhere...why?? it just complicates matters..
In short..ALL Platforms have there drawbacks and advantages..from what i have read AD's are it takes 2 memory spots for a timer but its half the price with great "Free" suport..
AB You can duplicate address's with no warning..It cost twice as much..and if you want support..you better be ready to shell out the bucks..
Modicon..Silly differences between platforms and softawre..mega bucks..but average phone support..No contract needed..
See good and bad points for each..
Terry Woods
Member
- Join Date
- Apr 2002
- Posts
- 3,170
"...from what i have read AD's are it takes 2 memory spots for a timer..."
That is true... no, wait a minute, no it's not... I mean... well... sometimes it is true... but then again... sometimes it's not.
That is the "idiocy" that I'm ranting on about. And it is all for the sake of supporting the primary idiocy... BCD as the normal number system... then there's the Octal issue...
And if other PLCs have similar issues... then they too have idiocies.
Gee... let's forget about having systems that speak English... I'd rather speak BORG! Wouldn't you?
If you were a damned "team-player" you would! By Golly!
One of the major things that makes me scratch my head is the importance that so many of you place on getting support from the PLC Mfg or Local Vendor. Don't you realize that, everytime you have to call for technical support that is simply another indication of one of two things... either...
1. The PLC you are using is NOT intuitive (as in reasonably designed, as in designed to be reasonable), and not properly described in the manual.
-OR-
2. You simply are not technically competent enough (which might explain why it is not intuitive... you do have to be somewhat logical... without getting obtuse - as in more Borg-like - in order to become aware of the "intuitiveness").
Why are there those that brag of the "intuitiveness" of their PLC, and yet, at the same time, proclaim the great technical support?
Just for the record... in the distant past, I did indeed proclaim the Talent and Expertise available at the TI (Siemens) support site in Tennessee. That was when I was trying to come to terms with an HMI program named CVU (Control Vision Unit). CVU was very poorly documented. It appeared, very early on, that I was better at it than they were. Since then, I haven't called them. And I've NEVER called them with a PLC question. Is it me? or the PLC?
If as intuitive as you say... why the dependancy on technical support?
That is true... no, wait a minute, no it's not... I mean... well... sometimes it is true... but then again... sometimes it's not.
That is the "idiocy" that I'm ranting on about. And it is all for the sake of supporting the primary idiocy... BCD as the normal number system... then there's the Octal issue...
And if other PLCs have similar issues... then they too have idiocies.
Gee... let's forget about having systems that speak English... I'd rather speak BORG! Wouldn't you?
If you were a damned "team-player" you would! By Golly!
One of the major things that makes me scratch my head is the importance that so many of you place on getting support from the PLC Mfg or Local Vendor. Don't you realize that, everytime you have to call for technical support that is simply another indication of one of two things... either...
1. The PLC you are using is NOT intuitive (as in reasonably designed, as in designed to be reasonable), and not properly described in the manual.
-OR-
2. You simply are not technically competent enough (which might explain why it is not intuitive... you do have to be somewhat logical... without getting obtuse - as in more Borg-like - in order to become aware of the "intuitiveness").
Why are there those that brag of the "intuitiveness" of their PLC, and yet, at the same time, proclaim the great technical support?
Just for the record... in the distant past, I did indeed proclaim the Talent and Expertise available at the TI (Siemens) support site in Tennessee. That was when I was trying to come to terms with an HMI program named CVU (Control Vision Unit). CVU was very poorly documented. It appeared, very early on, that I was better at it than they were. Since then, I haven't called them. And I've NEVER called them with a PLC question. Is it me? or the PLC?
If as intuitive as you say... why the dependancy on technical support?
LOL..All i can say Terry is thank god i dint work for you.. I think i would have gone insane...
As for...
2. You simply are not technically competent enough
You cant resist can you? You consistently take digs at people who don't know as much as you.. I am technically competent to do anything..GIVEN the correct guidence..If i choose guidance by sitting down and spending 6 hours reading a manual to figure out why a line is down then so be it..If however i spend 30 mins or so on the phone with a Tech support agent..I call that good judgment...
That being said if you are lucky enough to work with only one or two products then you should know them..But wait how do you get to know them..By LEARNING..How do we learn?? READ the manuals..Opps there is something here i don't quite understand...Hmmm what should i do now.. I Know i will just just quit because i obviously i am not technically competent to do this.....
As for...
2. You simply are not technically competent enough
You cant resist can you? You consistently take digs at people who don't know as much as you.. I am technically competent to do anything..GIVEN the correct guidence..If i choose guidance by sitting down and spending 6 hours reading a manual to figure out why a line is down then so be it..If however i spend 30 mins or so on the phone with a Tech support agent..I call that good judgment...
That being said if you are lucky enough to work with only one or two products then you should know them..But wait how do you get to know them..By LEARNING..How do we learn?? READ the manuals..Opps there is something here i don't quite understand...Hmmm what should i do now.. I Know i will just just quit because i obviously i am not technically competent to do this.....
Terry Woods
Member
- Join Date
- Apr 2002
- Posts
- 3,170
Refer to Item-1.
Yea AD might be a bit behind in the technology in their PLCs. But then I can buy an AD system for half the price of and AB system and it’s capable of doing just about anything that an AB system can do. I think it’s kind of like, I can buy a car with seat warmers in it. But can I drive any better because my a$$ is warm? No.
Can we let this thread die now?
Can we let this thread die now?
elevmike
Member
1. The manual DOES explain the difference between the Accumulating Timers & the regular timers. AND DS4 also has an explanation of this when you select the TMRA, or TMR box, or another box. But if you DONT take the time to read the manual or read the description window, whose fault is that?
2. AD tech support will also tell you, (with no hassle) if you call and ask. (Toll free call BTW). But you should be embarrassed to ask, IMO anyway.
3. I've called tech support maybe 4 times in the last 5 years. One was a real stupid question that was actually clearly answered in the manual, One was a 240 CPU firmware issue that was corrected with a FREE replacement firmware chip that arrived the very next day at 8:00 am. (I had a NEW manual and an OLD CPU); One was about interfacing a component NOT supplied from AD; and one turned out to be a component that was damaged by us. Oh.. there was another issue regarding AC inputs not picking up when a square wave output inverter was used for a back up power supplies...So does that make me incompetent or AD manuals poorly written? Neither by a long shot.
When the occasion has happened to call AD tech support, I've never waited in the que for more the 5 minutes, but usually just a few seconds. This gives me the impression that they are not exactly overwhelmed with tech support calls....Kinda like the Maytag man, possibly bored out of their wits, and dying to hear the phone ring. If you've noticed a few from AD tech support frequently haunt this site. Likely due to the possibility that they aren’t inundated by phone calls...
4. As far as the limitations of AD over brand X, there may be some, but I haven’t run in to that problem as of yet. As a matter of fact, about a year ago we very successfully completed a project with AD PLCs that our competitors, and the project consultant insisted couldn’t be done by anything other then CLX.. To this day I still don’t understand why they thought so...Maybe I'm just too ignorant to know better...
To sum it up, what attracts me to AD isnt necessarly the product, (as far as my needs go), but the way they run their operation. I spend much less time quoting, designing a panel, and ordering the components, then I do with any other brand. My time is valuable to me an our operation. Due to that alone we wouldnt be as competitive as we are without AD.
2. AD tech support will also tell you, (with no hassle) if you call and ask. (Toll free call BTW). But you should be embarrassed to ask, IMO anyway.
3. I've called tech support maybe 4 times in the last 5 years. One was a real stupid question that was actually clearly answered in the manual, One was a 240 CPU firmware issue that was corrected with a FREE replacement firmware chip that arrived the very next day at 8:00 am. (I had a NEW manual and an OLD CPU); One was about interfacing a component NOT supplied from AD; and one turned out to be a component that was damaged by us. Oh.. there was another issue regarding AC inputs not picking up when a square wave output inverter was used for a back up power supplies...So does that make me incompetent or AD manuals poorly written? Neither by a long shot.
When the occasion has happened to call AD tech support, I've never waited in the que for more the 5 minutes, but usually just a few seconds. This gives me the impression that they are not exactly overwhelmed with tech support calls....Kinda like the Maytag man, possibly bored out of their wits, and dying to hear the phone ring. If you've noticed a few from AD tech support frequently haunt this site. Likely due to the possibility that they aren’t inundated by phone calls...
4. As far as the limitations of AD over brand X, there may be some, but I haven’t run in to that problem as of yet. As a matter of fact, about a year ago we very successfully completed a project with AD PLCs that our competitors, and the project consultant insisted couldn’t be done by anything other then CLX.. To this day I still don’t understand why they thought so...Maybe I'm just too ignorant to know better...
To sum it up, what attracts me to AD isnt necessarly the product, (as far as my needs go), but the way they run their operation. I spend much less time quoting, designing a panel, and ordering the components, then I do with any other brand. My time is valuable to me an our operation. Due to that alone we wouldnt be as competitive as we are without AD.
Terry Woods
Member
- Join Date
- Apr 2002
- Posts
- 3,170
...and the Sun does travel around the Earth.
I believe that to be reasonable because there's a manual somewhere that says it is so.
I believe that to be reasonable because there's a manual somewhere that says it is so.
bernie_carlton
Lifetime Supporting Member + Moderator
If PLCs were intuitive and their structure and method of operation was obvious without need for any documentation whatsoever then manuals would not be necessary. Except in Terry's case (and possibly others) most of us must read those manuals to understand the operation. There we discover the methodology that the builders of the PLC used in their design.
This design probably varies from the perfect one which Terry has drempt up. I am looking forward to the availability of the 'Terry PLC' which has no need for manuals. Its design is already perfect for all possible applications. The interface is a cap which we place on our heads so that it can read our minds and be programmed directly without touching a keyboard or reading a manual.
Unfortunately the PLCs I program sometimes take the difficult path of doing what I program to do instead of what I want them to do. Then I have to read the manual. Sigh.
This design probably varies from the perfect one which Terry has drempt up. I am looking forward to the availability of the 'Terry PLC' which has no need for manuals. Its design is already perfect for all possible applications. The interface is a cap which we place on our heads so that it can read our minds and be programmed directly without touching a keyboard or reading a manual.
Unfortunately the PLCs I program sometimes take the difficult path of doing what I program to do instead of what I want them to do. Then I have to read the manual. Sigh.
Similar Topics
Hello everyone,
I am new to your forum but I did buy the learning book afew years back.
I need to do some programming and need advice on what is...
I have some logic that I have written within a 5380 series controller that tracks the time an event is started, while the event is running an RTO...
Hi all,
I have a simple question that I have overcomplicated and gotten stuck on. I have a variable, we can call it "light" that I need to stay...
Question to anyone with ideas about my thoughts on upgrading a very vintage timer, which is being used to switch between 2 5hp domestic water...
why my timer only executes once here? After first time i use it, ET stays at 0ms all the time. It is in FB