mitsubishi melsec q : modular programming in ladder

[qvolker]

hey all,

i'm looking for an elegant way to programm modularly in ladder on mitsubishi q series. the amount of software being developed at the place where i am working right now is expected to increase, so we think it would be good to share some kind of software library between the developers.

it would be an advantage, if we didn't have to change those routines at all, only adjust configuration data, when some piece of the library is used on other hardware.

i'm a bit lost with this one because my background is rather c than automatisation. so far i only came up with one idea that seems feasible to me...

a simple example:
some frequency drive at
X400 (alarm)
Y600 (motor off)
Y601 (motor on)
D1000 (speed)

now i store the configuration data separately in file registers:
R1000: 0 (actual status)
R1001: 400 (input base address)
R1002: 600 (output base address)
R1003: 1000 (register base address)

the library would now contain a subprogram for that very device, like this:


P20:
-[<> FD0 Krunning]-+-------[MOV FD0 Z0]
+-------[+ K1 Z0]
+-------(SET Y0Z0)
+-------[MOV Krunning FD0]

meaning: if it's not already running, SET Y601 (hopefully) and set the state appropriately.


and the main program would call like this:

--||-----[CALL P20 R1000]-

to start it.


unfortunately it looks like it's impossible to create an instance of some gx-developer structure with these data so i could access them from the subroutine like this:

--[<> FD0.status Kbang]----[SET FD0.on]---
...etc. pp.

(or is it?)

any input/comment is greatly appreciated. how do you guys handle modularisation?

thanks in advance!
Volker.

 

[Unregistered]

yokel

Can you consider the use of GX-IEC Developer? This provides for precisely the features you describe where you can develop custom libraries of Function Blocks requiring only the assignment of I/O and variables to implement multiple instances of the same function. These blocks are then capable of being Imported / Exported to other projects.

 

[ushidayo]

Which version of GX Developer are you using?

The current version (8.something) has function blocks which can be shared across projects. It also has structured text programming, which may be more convenient for someone with a C background.

As the previous post says, GX-IEC Developer (formerly MEDOC PLUS) has custom libraries and functions blocks. GX-IEC Developer will give better structure to the source code than regular GX Developer. BUT GX IEC Developer is slow to update the screen when viewing a program online, and doesn't make use of the fact you can have multiple program files on Q series PLCs. Also, the compiled program created by GX IEC Developer is not as efficient as a program created in GX Developer.

I wish that Mitsubishi would take the best of both GX Developer and GX IEC Developer and create a single programming system. I think we will have to wait a while though.

Just a small bit of advice, don't use R data memory for regularly scanned logic because the access time is significantly longer than D register memory.

As for modularising software, it depends a lot on what the application is (process control, machine control, whatever). Generally, I group handling of analogue inputs in one program file, alarms in the next, Sequences in an SFC program file, data exchange with HMI in another program. After this I would have program files for automatic control of outputs based on the sequence step, PID loops, digital outputs and analogue outputs.

The main thing with PLC programs is that many people have to understand it, so keep things simple. Some people like to group by object, some people like to group by function (e.g. should an alarm be grouped with all other alarms or should it be grouped with a real world device like "pump"). In my experience, grouping by function is the simplest to understand, but grouping by object is the quickest to program.

Best Regards

 

[qvolker]

thanks for your replies.

my gx developer version is 8.22Y. Ushidayo, do you know where that function you mentioned (to save and load function blocks) is hidden away? thanks for the hint, that would be a great feature to use.

is there anybody using 'gx explorer' and is it any good?

as for the 'gx iec developer': i couldn't find it at meau.com, only at mitsubishi-automation.com. if there was a japanese version available and if it was available on the japanese market, it might help persuading my department, that it's not a solely european thing, i hope.

furthermore, the policy here is 'ladder only', so i'll probably get away with using FBs, but SFC and ST are frowned upon.

regards speed of R and D (thanks): i will read the values from R into D registers at initialisation time; that should do it, right?

i also changed the approach taken in structuring the program (it's for machine control, btw.):

it'll be using a FB per piece of hardware.

the programs will be grouped according to the structure of the machine (like 'infeed') having their status information accessible in some register by the main program, which is in turn taking action, if the status change demands.

by narrowing down the data path like this (allowing only the main program to exchange data with and among the subprograms) i hope to get a clearer design and better reliability. (hope, the speed penalty is not too severe, though.) - is that approach ok or am i misled?

again, any hints, comments very much appreciated.
best regards,
Volker.

 

[ushidayo]

To share function blocks in GX Developer try the following;

First create a project to hold your function blocks (or you may even wish to have a separate project for each individual block if you don't intend to use function blocks within function blocks).

After creating the function block(s), close that project and open a new one. In the new project, click the project pull-down menu and select copy. A dialogue box will open where you can select the project file that contains the function block you wish to use. After selecting the project file you will be able to select the function block to copy.

It is very basic (it won't tell you that you need to also copy function blocks that are referenced by the function block you are copying). But it might fit your requirements.

I haven't used GX Explorer, I think it is a "glue" application to link several different GX applications (developer, simulator, converter, etc.).

GX IEC Developer is not available in the Japanese market. It doesn't support many languages, and it doesn't seem to be developing as quickly as GX Developer has recently. It does give good structure to programs though, maybe that's because it's from Sweden .

Personally, I think that the SFC programming in GX Developer is very good. Almost as good as APT (used on TI PLCs), which still has no equal when it comes to SFC. SFC can make a complex sequence very easy to follow when compared to a ladder based sequence. Try it and demonstrate it to your colleagues if you think it will suit.

Yes, I agree that copying the R's to D's during power up would be a very efficient method. There is plenty of capacity in R memory so it is also good if you need to store recipe data.

One more thought, there is an application called GX Converter which enables import/export of GX Developer programs in text format. If you want to repeat sections of ladder and change some addresses for each "instance", try creating it in excel and import to GX Developer via the GX Converter software. (Remember, Ladder Diagram and Instruction List are interchangable. With Excel you can make a program in Instruction List, import to GX Developer, and view it as Ladder). To make life easier, create your 'master' in GX Developer, then export as instruction list to Excel, where you can copy and change addresses simply. People have been doing this for a long time with Allen Bradley PLCs as a quick way of generating the long sections of repetitive ladder that are often found in PLC programs. I often use this method and its probably why I group by function rather than object (e.g. all alarms in one section).

Best Regards