S
Stan Brown
On Thu Jan 13 21:57:57 2000 Jiri Baum wrote...
>
>> >If we have these three, let's have the remaining one, "invert". Partly
>> >for completeness, partly because it doesn't cost anything, partly
>> >because it'll probably come in handy sometimes.
>
>Stan Brown wrote:
>> Hmm it's realy unheard of. But I can't think of any real reason to not
>> have it. On the other hand, I can think of many reasons to never use it.
>
>It really freaks the electrician if you tell him not to worry about
>figuring out the N/O contacts (like it says in the diagram) and wire the
>sensor N/C
No, mine understand the concept of fail safe witing, and always ask which contact to bring in. Usually they already no, they just want confirmation.
>Seriously, though, you'd never use it in your design; you might use it
>in later kluges and workarounds (same as the other kind of forces, no?).
No, a force is a _cery short term_ testing solution. Never left in place after I walk away from the machine/process.
>> >> Then we have timer struts. These consist of a 16 bit word each for
>> >> preset, and accumulated values, and 16 bits of status, eg timer timing,
>> >> timer done.
>> >
>> >If we want uniformity, we could have these as three separate files.
>>
>> No, you miss the point. Thnif of a struct. Each of the three 16 bit
>> loactions in a given time struct are associated wiht _taht specific
>> timer. You might have may files of timers, each consisting of many
>> timer structs, each of these having the subcomponents.
>
>Yup - it's just an implementation question. If you make it a struct,
>then you have to have a 48-bit file. If you make it three files, you can
>use the existing 16-bit ones. Probably doesn't matter in the end. It's
>the difference between T[5].setvalue and T.setvalue[5]
Big difference as I see it. See my reply on timer executin engines.
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
>
>> >If we have these three, let's have the remaining one, "invert". Partly
>> >for completeness, partly because it doesn't cost anything, partly
>> >because it'll probably come in handy sometimes.
>
>Stan Brown wrote:
>> Hmm it's realy unheard of. But I can't think of any real reason to not
>> have it. On the other hand, I can think of many reasons to never use it.
>
>It really freaks the electrician if you tell him not to worry about
>figuring out the N/O contacts (like it says in the diagram) and wire the
>sensor N/C
No, mine understand the concept of fail safe witing, and always ask which contact to bring in. Usually they already no, they just want confirmation.
>Seriously, though, you'd never use it in your design; you might use it
>in later kluges and workarounds (same as the other kind of forces, no?).
No, a force is a _cery short term_ testing solution. Never left in place after I walk away from the machine/process.
>> >> Then we have timer struts. These consist of a 16 bit word each for
>> >> preset, and accumulated values, and 16 bits of status, eg timer timing,
>> >> timer done.
>> >
>> >If we want uniformity, we could have these as three separate files.
>>
>> No, you miss the point. Thnif of a struct. Each of the three 16 bit
>> loactions in a given time struct are associated wiht _taht specific
>> timer. You might have may files of timers, each consisting of many
>> timer structs, each of these having the subcomponents.
>
>Yup - it's just an implementation question. If you make it a struct,
>then you have to have a 48-bit file. If you make it three files, you can
>use the existing 16-bit ones. Probably doesn't matter in the end. It's
>the difference between T[5].setvalue and T.setvalue[5]
Big difference as I see it. See my reply on timer executin engines.
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc