I have a very similar problem.

I want to read the LADDR of an input. But I have to use the IO2MOD function inside an FB which has the input as an IN variable.

With the function GetSymbolName i can read the signal name from the IN variabel as a string, for example "DI2".

I can use the IO2MOD function with the symbolic name of the input, but I cannot use the string i read.

So is there any way to use a string as a symbolic name input to IO2MOD?

------------------------------------------------------------------------------------------
Split from Convert STRING to VARIANT.

JanPetersen

I want to read the LADDR of an input.

<snip>

So is there any way to use a string as a symbolic name input to IO2MOD?

There's no such system function.

But you can always write such a thing. One long CASE should do this. Of course this will be project specific and valid until you alter tag tables. But maybe it (i.e. source code generation) can be automated with the Openness.

Hi Jacek,
Could you go a little bit more into details how you imagines that Case function?

I have a function that provides me with the MLFB number of every IO module, the LADDR, the IO address and the length of the IO area. So I know basically which IO addresses I have in my PLC. 

If there is any way to use this information as an input to the IO2MOD function I could build up a list over all IO addresses and their Tag name which would solve my problem.

But is this possible during runtime?

Hi Jan.

There is much tradition of Siemens PLCs you are fighting for asking to have a user STRING parameter be used to link to symbolic address. They are moving closer the PC world but not 100% there yet.

Could you please explain the functionality that you would want. Forget about how to do it - make that a black box in your mind. Just explain what / how do you want to feed into the black box and what do you want out.

Also keep in mind

- Functionality dynamically in runtime or before shipping the equipment.

- Functionality by anyone with a password access or a technician that has access to TIA Portal.

- Could someone prepare a SD card to load the PLC with.

BR

Hi,

Yes, we are feeling quite limited by the equipment and the engineering tools. 

The black box I want to create is a kind of generic input driver. The engineer can get the block from our library and needs only to connect the PLC input (like I5.0 or IW10, represented by their symbolic name). Inside the driver I want to be able to identify the type of input module, signal type for analog inputs (4-20mA, 0-10V, etc). I also want to be able to check if the quality information is activated and then read the Quality bit from the module.

And we do not want the engineer/user of the block to be required to do anything more than to connected the actual input signal.

JanPetersen

Hi,

Yes, we are feeling quite limited by the equipment and the engineering tools. 

The black box I want to create is a kind of generic input driver. The engineer can get the block from our library and needs only to connect the PLC input (like I5.0 or IW10, represented by their symbolic name). Inside the driver I want to be able to identify the type of input module, signal type for analog inputs (4-20mA, 0-10V, etc). I also want to be able to check if the quality information is activated and then read the Quality bit from the module.

And we do not want the engineer/user of the block to be required to do anything more than to connected the actual input signal.

 Please be patient with me -

What makes your description different than designing an FB block where the "junior" can just connect all the information (you mentioned I5.0 and IW10) through IO parameters. What needs to happen inside the FB that requires STRING -> TAG NAME.

There are several things that we want to know about the connected input signal

- Scaling for an analog input. Is it unipolar or bipolar?

- Does the input module provide a quality bit or not?

- MLFB of the input module

Of course the engineer could add this info to dedicated inputs on the FB, put this requires more work, is less flexible and higher risk for errors.

Hello,

There is no further positive suggestions I can make for this requirement.

@jacek:

jacek d

The topic went further. Some new infos came out. I checked something. And the question arose. Why don't you pass the IOs as Variants?

I am not following your train of thought on this matter.
Could you please explain a little more.

EDIT:
Did you mean something like:

Thank you.

BR

Exactly.

Also you can: 

CASE TypeOf(#new) OF

Bool:

   VariantGet(SCR:=#new,DST=>#yourTempBool);

Byte:

   VariantGet(SCR:=#new,DST=>#yourTempByte);

//and so on ...