J
Different types of I/O modules have different scaling for the same thing.
Some modules I have used are scaled 800-4000 for a 4-20mA signal, other are scaled 400-2000, yet other are scaled 0-65535 and so on
I would like to be able to handle this in the I/O driver to be able to change from one type of module to another without affecting the rest more than necesary.
For analog signals this require an scaling factor and an offset Possibly together with limits for maximum and minimum values. It could also be done by assigning the end points for the logical and physical limits (like 0-65535 -> 200-4000).
Possibly a "out of range" signal could be generated as a pair of optional digital inputs for each analog input.
This can be done separately if necesary but I would like to see it in the I/O driver.
/Johan Bengtsson
----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
-----Original Message-----
From: MIME :[email protected] [SMTP:MIME :[email protected]]
Sent: Thursday, January 27, 2000 8:27 PM
To: [email protected]
Subject: Re: LinuxPLC: Forcing
On Wed, 26 Jan 2000, Rick wrote:
> I think all signals that are output to hardware require a scaling
> factor. In the case of a bit the scale factor is either 1 or -1 or 0.
> In instances where confusion is likely use the default scale factor of
> 1.
What would be the purpose of this scaling factor?
What would it do to a bit, word, float, int and all other data types?
> I think there is also secondary need that is somewhat related. There
> have been many times when I wished I could invert a rungs result before
> writing it to the coil. I always ended up adding another rung to do the
> inversion. What if we had an inverting coil that be selected instead of
> a normal coil? This would also address the "invert need" in an obvious
> and un-hidden way.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
Some modules I have used are scaled 800-4000 for a 4-20mA signal, other are scaled 400-2000, yet other are scaled 0-65535 and so on
I would like to be able to handle this in the I/O driver to be able to change from one type of module to another without affecting the rest more than necesary.
For analog signals this require an scaling factor and an offset Possibly together with limits for maximum and minimum values. It could also be done by assigning the end points for the logical and physical limits (like 0-65535 -> 200-4000).
Possibly a "out of range" signal could be generated as a pair of optional digital inputs for each analog input.
This can be done separately if necesary but I would like to see it in the I/O driver.
/Johan Bengtsson
----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
-----Original Message-----
From: MIME :[email protected] [SMTP:MIME :[email protected]]
Sent: Thursday, January 27, 2000 8:27 PM
To: [email protected]
Subject: Re: LinuxPLC: Forcing
On Wed, 26 Jan 2000, Rick wrote:
> I think all signals that are output to hardware require a scaling
> factor. In the case of a bit the scale factor is either 1 or -1 or 0.
> In instances where confusion is likely use the default scale factor of
> 1.
What would be the purpose of this scaling factor?
What would it do to a bit, word, float, int and all other data types?
> I think there is also secondary need that is somewhat related. There
> have been many times when I wished I could invert a rungs result before
> writing it to the coil. I always ended up adding another rung to do the
> inversion. What if we had an inverting coil that be selected instead of
> a normal coil? This would also address the "invert need" in an obvious
> and un-hidden way.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc