R
I am unlikely to make any significant contributions code wise as I am not well versed in C anymore, having forgotten most of what i did years ago due to no longer using it. I'd like to approach some issues from a user prospective.
1. I' d generally agree that a PLC and an HMI "ought" to be seperate machines. However, I don't think it is appropriate for the LinuxPLC group to restrict it so that it has to be done that way. That should be a decision made by the implementor of the control system.
2. Before people go crazy and start writing code perhaps some thinking should be put into what the implementor of the control system is going to
need. I would like to see something readily usable by me as a PLC replacement, not some hacker's delight (no offense intended). The thing will never get any wide acceptance unless it is usable by people who are not C programmers or Linux experts, much the way people who are not WinNt experts can still implement projects using commercial packages.
I'd like to see something that:
a) Runs ladder logic
Because it is the most commonly used language for industrial control. Perhaps IEC1131 since it is already a standard.
b) Allows for unlimited online programming
Because it is near impossible to shut down most processes to make a minor change. Continuous processes are not continuous if you have to shutdown to add a temperature switch.
c) Allows for user defined functions
Because once you do something, its nice to not have to do it over. With many people writing user defined functions, if they choose to make them public, in a short period of time we could have thousands of functions available to cut
and paste as needed.
d) Supports many different I/O structures.
Regardless of some people in this effort who dislike proprietary I/O structures, the fact is that there are lots of 1771 I/O racks out there with old processors on them. It would be nice to retrofit an old AB installation without having to replace the existing I/O.
Towards this end, instead of pointing people towards I/O buses that have a small percentage of the market, why not open up and as a very high priority make drivers available for cards to interface to AB RIO and DH, Modbus+, and Genius, along with Devicenet, profibus, interbus, etc. (I didn't mean to leave anyone out, just gave a few examples).
e) supports some form of Netdde or other straightforward way of communicating with existing SCADA systems. These things can't operate in a vacuum.
g) needs drivers to communicate with existing common PLCs. AB/Modicon/GE, etc. The fact is that the PLC companies are not going to go away. The LinuxPLC will need to have a way to deal with them. In fact, it maybe ought to have the communications capablity to act as a traffic director for multiple brands of PLCs simultaneously.
3. high speed may not be that important. most automation projects do not involve this requirement. (more an observation then anything else).
Just a few random musings.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
1. I' d generally agree that a PLC and an HMI "ought" to be seperate machines. However, I don't think it is appropriate for the LinuxPLC group to restrict it so that it has to be done that way. That should be a decision made by the implementor of the control system.
2. Before people go crazy and start writing code perhaps some thinking should be put into what the implementor of the control system is going to
need. I would like to see something readily usable by me as a PLC replacement, not some hacker's delight (no offense intended). The thing will never get any wide acceptance unless it is usable by people who are not C programmers or Linux experts, much the way people who are not WinNt experts can still implement projects using commercial packages.
I'd like to see something that:
a) Runs ladder logic
Because it is the most commonly used language for industrial control. Perhaps IEC1131 since it is already a standard.
b) Allows for unlimited online programming
Because it is near impossible to shut down most processes to make a minor change. Continuous processes are not continuous if you have to shutdown to add a temperature switch.
c) Allows for user defined functions
Because once you do something, its nice to not have to do it over. With many people writing user defined functions, if they choose to make them public, in a short period of time we could have thousands of functions available to cut
and paste as needed.
d) Supports many different I/O structures.
Regardless of some people in this effort who dislike proprietary I/O structures, the fact is that there are lots of 1771 I/O racks out there with old processors on them. It would be nice to retrofit an old AB installation without having to replace the existing I/O.
Towards this end, instead of pointing people towards I/O buses that have a small percentage of the market, why not open up and as a very high priority make drivers available for cards to interface to AB RIO and DH, Modbus+, and Genius, along with Devicenet, profibus, interbus, etc. (I didn't mean to leave anyone out, just gave a few examples).
e) supports some form of Netdde or other straightforward way of communicating with existing SCADA systems. These things can't operate in a vacuum.
g) needs drivers to communicate with existing common PLCs. AB/Modicon/GE, etc. The fact is that the PLC companies are not going to go away. The LinuxPLC will need to have a way to deal with them. In fact, it maybe ought to have the communications capablity to act as a traffic director for multiple brands of PLCs simultaneously.
3. high speed may not be that important. most automation projects do not involve this requirement. (more an observation then anything else).
Just a few random musings.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc