CODESYS - the IEC 61131-3 automation software

Welcome to the official CODESYS Forum by 3S-Smart Software Solutions GmbH | A member of the CODESYS Group
Deutsche Version English version russian version 
It is currently Sat Dec 15, 2018 2:26 pm

All times are UTC+01:00




Post new topic  Reply to topic  [ 2 posts ] 
Author Message
 Post subject: Structuring of program
PostPosted: Fri Nov 30, 2018 12:19 am 
Offline

Joined: Thu Jul 09, 2015 9:55 pm
Posts: 25
Iam to make a simple plant with multiple process lines. Each process line consists of a pump driven by a VFD over modbus and a pressure transmitter. A PID is controlling the motor speed to keep a constant pressure.

What I'm wondering is how I should structure the program for fast setup in later projects.

I'm thinking a function block for each process line, such that a process line can easily be intiated with the required content.
As I mentioned the VFD has modbus TCP communication, and hence has several process words and a status word associated with it.
How should the function block for the VFD be structured to handle the I/O from the fieldbus (when it is called inside the processline FB), and also possible be able to handle different drives for each process line, ie. different setup of the fieldbus I/O words.

The pressure transmitter is a simple 4-20mA sensor. Should it also have its own pressure transmitter?

Everything is to be controlled from a visu, no external control.


Top
   
PostPosted: Fri Nov 30, 2018 6:34 am 
Offline

Joined: Mon Oct 01, 2012 8:33 am
Posts: 47
1. Many people define global tags using the % placeholder for the address and then use the codesys I/O assignment tools to bind the actual I/O points to the tags.

2. If it were me I would build simulators for each of the lines so I could test everything without any I/O. In this case I/O points would be connected to the simulator and virtual I/O points would be connected between simulator and control function blocks. When simulator is disabled I/O is passed to/from the control FB. When it's enabled then feedbacks are supplied by the simulator rather than I/O and control outputs are sent to the simulator rather than written to outputs.

3. There is an art to making FBs, or at least there is for good ones. Think hard and long how best to decompose the problem. Don't use more than 2 or 3 levels of inheritance, unless you really know what you're doing.

4. Consider using program POUs for each line and then use a couple of your custom FBs in the program. This way local variable scope can be used for tuneup constants and intermediate variables. The program can then be copy/pasted for the next line and then edited for any differences.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 2 posts ] 

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited