One program, but two or more similar machines

[Marbek_Elektronik]

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?

[Loader]

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

[oiltronic]

If parameters don't work for this application then consider a spare input tied high or low.

[Marbek_Elektronik]

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.

[FluidPowerTom]

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.

[Marbek_Elektronik]

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.

[FluidPowerTom]

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.

[Marbek_Elektronik]

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?

[FluidPowerTom]

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?

[Marbek_Elektronik]

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?

[FluidPowerTom]

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.

[Marbek_Elektronik]

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.

[oiltronic]

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:

• Make separate software applications for each of the 3 machines, and put common state-machine steps into pages that are exported into a personal library and shared.  The shared pages can also have input parameters which select which parts of the state machine are used.
• Use the same application for all 3 machines, then use control logic and boolean switches, along with read-only boolean parameters (or NV parameters set by the Service Tool, or an external input set high or low), to select which sections of the software state machine are enabled.

Sharing classic screen software between applications is more difficult:

• Make a new application for each machine by copying an entire application, then make the changes.  (I don't need to make major changes to a screen application after it ships, so this works for me.)
• Make a single application for all 3 machines, and make lots of different screen areas for the different parts that are enabled according to the same parameters or inputs mentioned above.  I've done this for one machine where the operator can select what to display.

The Vector-based editor is new to me but I noticed it has import/export capability, which might be nice.

[Marbek_Elektronik]

Thanks,
I will try it and will document my way here in the forum.

[ZanInno]

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.