Hi All, I'm new to the list here, Not sure what the protocol is for new users, so I'll give a quick intro then ask my question. I'm currently working as a contract software engineer, but one of my previous employers was CI Technologies (makes of the Citect SCADA Package). I Spent a good 2 and a half years working in support and a further 2 years doing engineering for them. Now the question. I'm looking at writing some software for the Process Control Industry as a side project, and having a quick look back it would appear that not all that much has changed in the last two years since I left CI. Can anyone tell me please what you feel would be a GOOD application that you could *really* use, and I'll look into whats involved in writing one. I've always felt the Process Control industry was at least 5 years behind the rest of the software world. I'm not sure if thats the case any more. I'd be very interested to find out. Thanks Kindly, Emil Nadinic.

 

Hi Emil, Its nice that u r looking towards software development in Process Industries. For this I would like to have some discussion with you.Can you just send me your mail ID. My email ID is: [email protected] I am interested in such stuff. Regards, Sachin Mane Application Engineer ProcessBiz Technologies

 

Emil, Could you simply show for all of us some bloc diagram, in order to explicit in picture type of maths what going on inside the black box. Expanding completely: Derivative and integration in term of the accumulated samples in the buffer. If you can, explicit led/lag as well. In my view that would be a substantial exposure of your knowledge applicable to many of the list !!! Thanks. <[email protected]>

 

Automation and Process engineers must know an awful lot of stuff, so they cannot expect to also be expert software enginners. Their needs are severely neglected in the software toolchain. Lets start by stating two facts: 1) C is a very useful language for automation engineers, who must often do weird and wonderful things with unusual data structures, and do it quickly. It is also very useful to do things like direct API calls to things like serial ports and winsock. 2) Visual Basic makes it very simple to re-use code by means of active X components, and build large systems out of small snippets. It is also very easy to integrate applications into the windows/office environment. It is also useless as a substitute for what we said in point 1. So, the obvious solution would be to use ANSI C/C++ to write functional blocks in the form of Active X components. Alas, as anybody who has tried this will testify, life is not so simple. The COM model used for Active X is incompatible with standard data types and, amazingly, the windows API itself. Major C compilers (OK, VC and Builder) do provide wizards for creating ocx's, but they produce numerous files and reams of code in the process, which programmers must delve into and modify all over the place to make their interface. Imagine I could develop my functions in a simple CLI program, using the main function as a test container for a C++ object that contains the functionality of my control. I put public getter and setter functions for properties, indicating them as properties with a pragma directive. These pragmas go in a specific header file along with enums and structure declerations (destined to become user data types). In the header I also declare events in the form of extern functions. Now, before de-bugging, I use 'THE PROGRAM' to parse the header file and generate an object module that will eat the event function calls and display them when called. Once I have debugged the class, I strip out the main and compile it as a DLL and use 'THE PROGRAM' again to wrap my class in an active X container. This container receives the event function calls, handles data type conversions, and arranges for the correct calling of the getter and setter functions. Perhaps some way of doing this already exists, if so I would like to know about it! If not, then there is a need for 'THE PROGRAM'.

 

My humble appologies, I should have made it a little more obvious that I was leaning to the SCADA side of the table, not the PLC programming side. My appologies. Emil.