PLUS+1 User Forum

PLUS+1 Software => General controls => Topic started by: Marbek_Elektronik on October 27, 2015, 10:31:50 PM

Title: One program, but two or more similar machines
Post by: Marbek_Elektronik on October 27, 2015, 10:31:50 PM
How do you do this?:

You have 2 or more machines which are similar.
But there are little differences in state-machine.

What is the best way to use only one program?

"call modules" or "read only parameter files"  are not the solution for this problem, I think.

Do you have an idea?
Title: Re: One program, but two or more similar machines
Post by: Loader on October 28, 2015, 08:12:15 AM
Hi, I think:
You can use a parameter to identificate the machine type and you can to condition the transition between states according to the value of parameter.
I hope this is possible with your system!
Bye
Title: Re: One program, but two or more similar machines
Post by: oiltronic on November 05, 2015, 11:37:58 AM
If parameters don't work for this application then consider a spare input tied high or low.
Title: Re: One program, but two or more similar machines
Post by: Marbek_Elektronik on November 05, 2015, 05:18:27 PM
Thanks,
but there are not only differences in parameters, also in statemachine.

So, it is not possible to ask parameters or inputs to activate one software.
Title: Re: One program, but two or more similar machines
Post by: FluidPowerTom on November 06, 2015, 11:41:39 PM
Have you used the Call POU structured text functionality?  In addition to input and output variables it has an input for a True/False that determines if the POU runs or not.
Title: Re: One program, but two or more similar machines
Post by: Marbek_Elektronik on November 07, 2015, 08:39:11 AM
Hi,
I worked with Danfoss Guide alone.
Is it an advantage to use Codesys? I can't program in codesys.
I like Danfoss Guide.

I think, the best way for my problem is, to write two programs and to use the same subpages for same doing.
Copying display from one to another will be a problem? - I will test if I find there a good way too.
Title: Re: One program, but two or more similar machines
Post by: FluidPowerTom on November 09, 2015, 11:28:03 PM
The Call POU is in the Component tab within the Connection group.  It's fully functional in GUIDE, and I've used it a lot.  In the Danfoss documentation it is the Structured Text feature.
Title: Re: One program, but two or more similar machines
Post by: Marbek_Elektronik on November 10, 2015, 12:02:22 AM
this components are not availlable on DP610. I have seen them on DP610TM.

And the 2. problem is: I can't program in Codesys (=struktured text?)

It is the same effect to use call modules in Guide?
Title: Re: One program, but two or more similar machines
Post by: FluidPowerTom on November 11, 2015, 01:53:14 AM
I have never used the Modules in GUIDE before, but I just now spent some time researching this function.  I would say that Modules and POU's are very similar in effect.  Structured text isn't CoDeSys per se... CoDeSys includes six different programming languages which includes structured text as well as ladder diagram, sequential function chart, continuous function chart (which is basically what GUIDE is), instruction list, and some weird step chart.  The similarity is that this Structured Text is defined by the IEC 61131-3 standard.

Anyway, it sounds like what you're interested in is some way of having the microcontroller identify which type of machine it's installed in and then act accordingly.  Are you looking for ideas on how the microcontroller can identify the machine or how it can use that identification to trigger different logic?
Title: Re: One program, but two or more similar machines
Post by: Marbek_Elektronik on November 11, 2015, 02:51:59 PM
Hi,
if someone doesn't know programming in structured text, do yo suggest to learn this language?
I like Guide. But if it is better to use another language - OK....

We know the machine, so we don't want to automatically identify it. - Thanks.

In guide Call-Modules it ist not possible to place screens.
Is it possible to place in structured text POU's?

How do you make graphics in structured text?
Title: Re: One program, but two or more similar machines
Post by: FluidPowerTom on November 11, 2015, 07:03:32 PM
I didn't realize before that you were referring to screens.  No, there's not a way to do screens in GUIDE structured text.  I would say that there's no great reason for you to learn Structured Text unless you have a need for it. 

I'm still not 100% clear on what you're needing to do, but it sounds like it may have more to do with functionality within the screen editor.
Title: Re: One program, but two or more similar machines
Post by: Marbek_Elektronik on November 11, 2015, 08:28:17 PM
There are 3 Softwares which have many common pages and screens.
But this softwares are to different to manage this with parameters.

So, if I change a page in one software, I have to change it in the other softwares too.

But the problem ist the classic screen editor.
I have to  think about it, how to realize this.
Title: Re: One program, but two or more similar machines
Post by: oiltronic on November 13, 2015, 08:15:22 PM
Sounds like you have two parts of the software you want to share between machines that are only a little bit different:  state-machine logic and screen software.  Each are handled in different a way.  And how you do it depends how much of the software is the same and how much is different.
For sharing state-machine code between machines there are two basic options:
Sharing classic screen software between applications is more difficult:
The Vector-based editor is new to me but I noticed it has import/export capability, which might be nice.
Title: Re: One program, but two or more similar machines
Post by: Marbek_Elektronik on November 15, 2015, 10:47:41 AM
Thanks,
I will try it and will document my way here in the forum.
Title: Re: One program, but two or more similar machines
Post by: ZanInno on November 29, 2015, 06:15:04 PM
I recently did a project that used 2 controllers with the same program.  I used two inputs to identify where the controllers were installed.  If the controller were was installed on the RH side, "input1" was 12V.  If it was on the LH side, "Input 2" was 12V.  By using these inputs, the code set an EEPROM var that would define the Node ID.  This allows the service to connect to each controller.  I also flashed the green controller light in a different sequence depending on the node id.

Now you can use that node ID / Input variable in your logic to have a different function depending on the location of the controller.