Subroutine import with dummy IDs

[Ausman]

Hi again,    (on another sad day for the world)

 

A very useful feature for me would be the ability to have a tick box present during the import subroutine process that lets you select whether or not to import all the user defined descriptions, or have them substituted with a "dummy".

 

I often import code, but invariably due to each project I work on needing vastly different aspects, it is just not possible to utilise the same numbers and descriptions.  But...and this is the crux of the ask....the ladder/routine construction is essentially the same.

 

It would be great if the import process could simply go through all the elements and anything that is not system related is changed to a "dummy" number and the description is blanked.  One would then only have to adjust labels and names to suit, but this would be far far easier than the current process which can get very confusing.  This way it would only be a case of progressing through that routine/ladder, finding anything that is "dummy marked" (perhaps a #, ?) and adjusting things via a few mouse clicks to match up to the current program.

 

cheers,

 

Aus    

[Joe Tauser]

+1

 

Keeping track of which MIs and MBs were in the exported routine is next to impossible, and it has stomped on code I've already written.

 

Joe T.

[Cara Bereck Levy]

@Ausmanand @Joe Tauser, I apparently missed this request way back in 2016 😖.
Apologies...🙏

However, it was recently referenced in another thread.

It should be doable--I need to give a definition to the team. 
Are there any points you (or anyone else) would like to clarify/add to the feature request?

 

O)h--and you are definitely referring to VisiLogic, yes?

[Flex727]

Yes, not sure how to implement in practice, but as I see it, if an operand is already in use in the receiving project *and has a different description* the importing operand should be reassigned to an unused operand and retain the description.

[Ausman]

Flex's answer plus "and the process generates a list of all operands involved for checking purposes".

Or another totally different way which would be great.  Have a special descriptor for ALL operands other than system ones, such that the import process adds a character, like a % or $ etc, to the operand's number and treats it as a totally separate entity.  As this isn't being immediately sent to the plc and is only there for further human involvement, nothing at the plc end needs to change.  At the start of the process a tick box should come up asking if the character should be added or not.  Such a process is "only" some extra coding for Visilogic, which would have to have the ability to display the extra character and also allow it to be displayed.  Compile would need to pick up any "uncorrected" operands, as well.  

I didn't say this would be easy, but it would make a vast difference to usability.

cheers, Aus

[kratmel]

I support Flex's words that the easiest way to implement a normal subroutine import is to find "Used operands" in the project. In the list of operands, we see the Use check box.

In the import process, a dialog should appear that will offer action only for operands that are already "used" in the project or not allowed in project (for example some upper MI not present in Samba). Not used allowed in project operand can be transferred without any prompt.

User has the next options:

- Replace with a new description of the operand,

- Leave present in project description,

- Change the operand numbering,

- Cancel the process.

It look's like Copy - Paste dialog in Explorer.

It should be noted that this method will allow you to transfer routines between different PLC  in which different number of operands present.

[Flex727]

12 hours ago, Cara Bereck Levy said:

It should be doable--I need to give a definition to the team. 

Is this really doable (in terms of time an effort needed by the people who maintain VisiLogic)? I feel like this is asking for the moon.

I'd much rather get direct copy and paste between two instances of VisiLogic.

[Ausman]

5 hours ago, Flex727 said:

I'd much rather get direct copy and paste between two instances of VisiLogic.

Very True, Flex.........but it would have to be along the lines of the copied info ONLY included operands and their numbers by default, with other separate things like powerup values, description etc  able to be specified by the user.   But also include Kratmel's ask for when there are 'out of type' range adjustments needed.

[Cara Bereck Levy]

OK--after the VisiLogic R&D people looked into this a bit deeper--it seems that the potential pitfalls are greater than we thought at first glance.

What they are proposing is to create a  CSV with before and after addresses.

I know it isn't the solution you requested...but it is helpful, isn't it?

 

 

[Flex727]

7 hours ago, Cara Bereck Levy said:

What they are proposing is to create a  CSV with before and after addresses.

I know it isn't the solution you requested...but it is helpful, isn't it?

Not sure. Can you clarify? If the resulting .csv only has the operands pertaining to the imported subroutine, then perhaps. If it's the same .csv that results from "Export Operands Descriptions" under the Edit menu, then it would seem redundant.

[John_R]

I've taken a 3-step approach to this in the past;

Cut the logic you want from one program and Paste it into a New project.

Skim through the logic and either blank out the operands with dummys, or fill in the known operands from the target program.

Cut and Paste paste into the target program without stomping on operands....

 

And of course it never hurts to save that interim project as an example for the next time you re-use that code....

[kratmel]

2 hours ago, John_R said:

And of course it never hurts to save that interim project as an example for the next time you re-use that code....

This is best practice. I created  "base" project with a pre-programmed interface for all Unitronics PLCs present in my cave. Power on logo, basic HMI function, standard INPUT connection with NC-NO switching and input simulation, OUTPUT connection with manual activation, ALARM screen ...

The main idea is to use the latest numbered MB, MI and other operands for this "base" project.

Importing subroutines in this case does not change anything in the "base" project.

Only connecting subroutines from many different projects can create a problem.

P.S. It is usually much harder to rework a project than to create a new one with "base" at hand.

[Ausman]

On 3/1/2022 at 11:16 PM, Cara Bereck Levy said:

but it is helpful, isn't it?

@Cara Bereck Levy   I personally think this would be too cumbersome to use.  Perhaps a much easier thing to implement would be my original suggestion, but by getting cut and paste between instances working as Flex suggested.  But only in such a way that the User can choose to import ALL or NONE operand references, ie just the layout, or layout with numbers.  The operands in a "No Number" paste would be ones that are outside the normal system, but with type.  This way they would show up in a Compile as not being corrected.  Not ideal, but a definite step forward. 

Anything that lets things be more easily copied between projects, other than subroutine imports, is good.

Agreed......Kratmel & John's base project idea is good and I often use such a thing, but if you are working on vastly different project types it can become very awkward to use as they don't quite match what's needed and can create headaches ironing out errors.

cheers, Aus