mitsubishi q series: software re-use / modular programming

qvolker

Member
Join Date
Apr 2005
Posts
9
dear list,

i am currently about to introduce some kind of software library at my workplace. the idea is that someone writes for example a function block to access a specific device, which is then used by everybody else.

problem so far was, that (for example) a frequency inverter of a certain type, device-mapped via cc-link, would use different base addresses in every machine, moreover, every device of the same type in the same machine resides (of course) at different places.

my approach is, since it's only the base address that's changing, let's supply the function block with the base address. simplified example: fictional device with just one input.

would be used like this:


+--------------+
---[bla_base_X]---| base_X |
| |
| |
---||-------------| action_a |
HMI button | |
+--------------+




the FB itself would be implemented like this, given that action_a only meant to switch some output on/off:



---||-----------[MOV base_X Z2]
SM400

---|^|-------+--[+ offset_action Z2 Z10]
action_a |
+--[SET X0Z10]

---|v|-------+--[+ offset_action Z2 Z10]
action_a |
+--[RST X0Z10]



where offset_action is the offset of that I/O point from the base address.

in this particular case it would of course be a bit of overkill, but i am about to use a similiarly organised FB to access a motor (mainly, because it saves a lot of time, if i don't have to look up the addresses of every single I/O of that motor every time i use one. i just have to copy the motor's FB and provide the base address.


so, finally, here are my questions:

* what do you guys think about it?

* will i run into troubles with execution speed? (i try carefully only to set the index registers when really neccessary, so i hope it won't take too much time)

* i haven't seen anybody programming like that (but then, industrial automation is not exactly my background) so i suppose there are reasons for that... (?)

* anything else, i should consider?

thanks a bunch in advance for your input on this!
best regards,
Volker.
 
Last edited:
What would be the actual advantage of doing it that way? May be I just can't grasp the concept, but I don't see the point. Would you mind explaining?
 
help me out here.

u are trying to control or observe what on the motor?
if u are trying to program a motor drive of such. which i think im off on this conclusion. i always remeber this when setting up motor drives. They are like people almost. they are very similar. bust all have just a little bit different details. only necessary in close tolerance or high speed control.

or my other guess. is that if all is good with motor aux. inputs.like O.L. contacts, starter aux contacts, encoder or tach.
if u are wonting to keep up with when and where certain things take place yes i like the idea. let me know some more details. i could use something like this attimes. but ive did it slightly different but wasnt easy..
 
> u are trying to control or observe what on the motor?

the motor was just an example. i'm planning to use generalised FBs for example for cc-link and q-motion watchdogs as well. as for the motor... i wrote an FB for a specific type of cc-link connected frequency inverter, but didn't use it in an actual machine yet. (mitsubishi E500, iirc). the function block has the following inputs:
base adresses (X, Y, Dr, Dw), start/run, stop, brake, desired frequency, command, and a couple of others. because the inverter's original inputs were quite ok, the FB's inputs don't differ too much. same goes for the outputs... i have a couple of convenience outputs and the original ones (just in case someone wants to do something incredibly clever with that motor).

the main feature is that you only have to supply the correct base address, and not to look up certain addresses (registers) every other minute. also, since you don't have to edit _anything_ when importing the FB, it's more unlikely you make a mistake on that level. of course, you still have to use the FB's inputs correctly.
if i am right, you can't do that, when you use "conventional" FBs, with the actual addresses (devices) in the header, because you would end up with importing one FB per motor, right? also you had to edit every of the headers.

what i end up with is an FB that everybody in the department can use for his development, hopefully resulting in a well-organised software library.

any other way how to achieve that functionality?


> motor drives. They are like people almost. they are very
> similar. bust all have just a little bit different details.
> only necessary in close tolerance or high speed control.

sorry, i can't follow you there... the interfaces of drives of one certain type are (hopefully) all identical. as far as all motors differ a bit (deep in their hearts) - yes maybe, but that wasn't exactly my concern ;-)


> if u are wonting to keep up with when and where certain things take place yes i like the idea.

if by that you mean: controlling the motor - yes.


> let me know some more details. i could use something like this attimes.

i will post a bit of the actual code later.


> but ive did it slightly different but wasnt easy..

i'd gladly have a look at your approach. thanks for the input!!

ciao,
volker.
 
Hi qvolker,

The personal message system on this website has a limit to how many characters can be included. So I'm sending my reply through the forum, I hope you don't mind.

Hi

I am more than happy to help you, I just hope my thoughts will be helpful.

I can see that you main aim is to improve the efficiency in writing PLC programs and also to bring a standardized programming "style". This is good and I wish more people involved in writing PLC programs would do this.

I currently write PLC programs to control machines used in the food and beverage industry. I also commission the software at the customer's factory. Quite often, I also commission machines for which the software has been written by another person. In cases when the software has been written by someone else, it is quite normal that they are in a completely different country and timezone. So if the machine doesn't work correctly or requires modification, then I must troubleshoot/fix the software without any assistance from the original programmer.

Sometimes the software I have to troubleshoot is easy to work with (good structure, readable, not unnecessarily complex). Occasionally, I have to spend ridiculous amounts of time troubleshooting software which has no structure at all, or the programmer has tried to be clever when a more simple solution works just as well.

In my experience nothing ever goes to plan. No matter how much time is spent in the office designing a control system, when you arrive at the customer's factory and install the machine you realize that there will be modifications required.

Also, my company services machines that we install. So I also have to look at problems with older machines running with control systems that are by now becoming obsolete.

What I'm trying to say is that, in addition to programming efficiency and standardization, attention must also be paid to maintainability of software. Someone will need to be able to fix or modify it during and after the machine is installed. Quite often this will be done while the machine is still running.

Imagine being in an extremely hot factory, sweat pouring down, kneeling in front of a control panel, your notebook PC connected to a PLC, you're trying to figure out why a production line has gone down, and the factory manager is shouting at you telling you that every lost minute is costing him a fortune. Oh and this is the first time you have ever seen this particular PLC program. I can tell you it isn't nice and I wouldn't wish it on anyone.

Anyway down to specifics, If you use a function block in a PLC program it must be well documented as to what it does or it's meaning must be intuitive. It takes a lot of effort to fully document a function block and also it is not easy to make this information easily available to whoever is viewing the program. Therefore only create function blocks that are intuitive. For example, a function block for a valve is fairly intuitive, it would include control of the valve (opening/closing), monitoring of position feedback (opened/closed) and fault handling (failed to open/close).

Your idea for an inverter drive function block has some merit. But control logic for inverter drives can become complex and varied. In my opinion a function block for an inverter is not really intuitive. Sometimes I have inverters which are only run at fixed speeds, some are linked to flow control loops, sometimes I want to take current and voltage readings (over CCLink). It depends on your situation, if your company always uses inverter control logic the same then maybe a function block will work.

Looking at your example for an inverter function block, I think your use of index registers to offset the addresses is a good approach. One thing I wouldn't do though is use SET and RST unless I really had no other option. I recently commissioned some machines where the software was full of SET and RST instructions. Quite often there were many rungs between the SET and RST of a particular bit. It was so difficult to read this program. Instead try to use self latching rungs, I'll try to explain an example below;

 
A B C D
-||----|/|---+---|/|--------( )--
|
D E |
-||----|/|---+


A : ON Condition
B : Prevents D from turning on if currently off
C : Prevents D from turning on and turns D off if already on
D : The bit being controlled
E : Turns D off but only if ON condition is not active.

This type of self latching rung is the most important part of PLC programming, consider it for a while if you didn't already know this.

Oh well, it's getting late here so I'll wind up for now. Please feel free to contact me again.

Best Regards
 
hey Ushidayo, thanks for your input on this!

the work is still in (slow) progress, so i'd be really happy about still more information - anybody?


...
> What I'm trying to say is that, in addition to programming efficiency and standardization,
> attention must also be paid to maintainability of software.

i actually (and maybe naively) hope that this will be a nice side effect of my approach.

> Anyway down to specifics, If you use a function block in a PLC program it must be well
> documented as to what it does or it's meaning must be intuitive. It takes a lot of effort
> to fully document a function block

i already documented it - and in my opinion it is actually quite comprehendible. making the
documentation available is btw. also a concern of mine. i don't really have a good solution to
that. but i would expect someone who goes out troubleshooting to grab the documentation off -
say some central documentation server.

i see 3 major benefits in using software libraries like that...
* development is quicker (it nearly drove me insane, when i used an AD converter in a
program for the first time - now i hope for: drag&drop deploying the FB, set base addresses,
connect I/O and no headaches with the I/O and buffer lists and the timing all buried in some
mitsubishi-style-not-so-ergonomical manual.

* development is less error-prone (works in 10 machines - will most probably do the same in
the next one)

* for the same reason the troubleshooting will be a bit easier, because the FB is probably
ok. also, since the interface is well-defined, it might even be easier to debug a program that
uses that FB


you surely have a point in that the programming is less intuitive than programming it directly
but i count on the black-box effect of the FB - i hope, after it has been tested enough, it
won't have to be debugged.

another negative point is the unflexible programming. that's what i also fear. so for
more exotic programmes i made the original interface-points available (still some convenience
gained, because of the
address translation), so i hope i cared for every need.

probably the worst is the 500 steps limit on FBs. there might be quite a lot of hardware
that can't be interfaced in 500 steps (e. g. 8-channel A/D converters - don't know yet if it
fits)

of course, not everything can be handled by an FB like that.

> One thing I wouldn't do though is use SET and RST unless I really had no other option.
> I recently commissioned some machines where the software was full of SET and RST
> instructions. Quite often there were many rungs between the SET and RST of a particular
> bit. It was so difficult to read this program. Instead try to use self latching rungs,
> I'll try to explain an example below;

thought, i was familiar with the concept - you are talking about things like below, right?



X K
-||-----+--------||---------(Y)
|
-||-----+
Y



K enables Y,
X switches it on, Y holds itself, even if X turns off again - but only as long as K is on


please correct me, if i got your example wrong:

A B C D
-||----|/|---+---|/|--------( )--
|
D E |
-||----|/|---+



>
> A : ON Condition
> B : Prevents D from turning on if currently off

in my opinion: if B is off, it even helps turning on D, isn't it?


> C : Prevents D from turning on and turns D off if already on
> D : The bit being controlled
> E : Turns D off but only if ON condition is not active.


what i see is D == !C AND (A AND !B) OR (D AND !E)
in words:
1. D is always off, unless C is off
2. D holds itself, if E is off
3. D turns on, if A is on and B is off

am i getting it right?


the main advantage of using RST and SET is speed (at least, i hope so). the PLC has to evaluate all the rungs, if you
use coils, so i had to swap my register set according to the needs of the moment quite a bit -
the 16 index registers are by far not enough.

if you only set and reset when needed you only have to swap when needed... and i tried to keep
setting and resetting close to each other (geographically, i mean). so i _hope_ it's not too
hard to read.

maybe i try indirect addressing with the registers and save the index regs for the I/O points
but in some cases even that might not be enough.

some more questions sprung up:
* is it true, that GX developer is reserving Z0 and Z1?? that would be.... not so nice.
* does GX configurator really automatically design function blocks? to what extent?


again, thanks in advance for input,
best regards,
Volker.
 
Last edited:

Similar Topics

Does anyone here have suggestions of open source SCADA software that can be used for Mitsubishi PLC FX3U Series. I want to monitor its data...
Replies
2
Views
2,780
I just want to read the software so i can understand a little about how this device works. Thank you!
Replies
2
Views
2,195
Hello All, I just want to ask what programmer software do I need to access a Q00J series PLC. I had tried GX developer V.7 and GX IEC developer...
Replies
4
Views
2,010
hie Chaps I am a trainee engineer . Recently, our company recently contracted a foreign firm to automate our underground winder. so they brought a...
Replies
1
Views
3,705
I work in a plant where there are about 12 of the older Mitsubishi PLCs, Series A1S. I need to loacate some older Software to Upload and Save the...
Replies
4
Views
11,713
Back
Top Bottom