How to code this expression , Using tags from plc

How too script :

  1. If (tag is true)
  2. Then (output tag) = true
  3. else (output tag) = false

The more detail you provide, the better the answer will be. Also, you have expression in the title, but script in the post, which one is it?

1 Like

...is there some reason the answer isn't just 'output tag = input tag'?

1 Like

Expression: if | Ignition User Manual

Scripting: Python If Statement

I wish to use script . So if a no contact(tag) is ON then turn on a output (tag).

How would i write this

Well, yes :smiley:

output tag = input tag
this would seem to be the simplest answer

Thank You , Using If and else how would it look

wait, why are you using a script, and why are you using ifs

It is in there Logic choices (ignition)

wait, sorry, trying to figure out the intent here. are you trying to figure out how to use if/else and use this as an example, or are you trying to solve this problem most effectively?

5 Likes

If you want to create a new tag that references another, read this documentation. You can use a reference or derived tag based on your needs.

If you are new to Ignition development, I would recommend Ignition SCADA Courses Online | Inductive University. This is free :slight_smile:

Yes I have lots of code too write using < > + and if too turn on plc outputs .So I was looking for examples of how too write to output tags in a plc

Expressions do not write to arbitrary tags. They can be a result for an expression tag. If necessary, you can use my Integration Toolkit to RePublish the result to an OPC Item, but the general solution is a script, and only a script.

Be aware that writing to another tag within a source tag's valueChange event is dangerous, as writes can stall. (Unless it is a memory tag--those cannot stall.)

The example you gave isn't great as the result is always the same as the input value.

In general pythons if..else syntacx looks like this:

if condition == true:
    #execute action for true condition
elif nextCondition == true:
    #execute action for the next condition
else:
    #execute default action.

elif is short for else if this allows for chaining multiple conditions into a single if statement. Only one of the execution blocks (if, elif, or else) will execute.

In your stated example the script to read a tag, and write its value to an output tag could look like this:

condtion = system.tag.readBlocking(['path/to/input/tag'])[0].value
outputValue = False

if condition == True:
    outputValue = condition
else:
    outputValue = False

system.tag.writeBlocking(['path/to/output/tag'][outputValue])

Since the output value is already False due to it's initialization, this can be simplified to:

condtion = system.tag.readBlocking(['path/to/input/tag'])[0].value
outputValue = False

if condition == True:
    outputValue = condition

system.tag.writeBlocking(['path/to/output/tag'][outputValue])

And because the outputValue will always be the same as the condition, we can further simplify that to this:

condtion = system.tag.readBlocking(['path/to/input/tag'])[0].value
system.tag.writeBlocking(['path/to/output/tag'][condition])

Which is why @Leor_Fishman said:

However, in Ignition, this is sub optimum, and other methods should be used for this simple example.

For more complex situations the syntax of an if statement doesn't change. If you can provide more information about something that you are struggling to get working then we will be better able to provide concrete advice on how that should be handled.

1 Like

Err, what do you mean by this? :fearful:

i assume valueChange is sync, and opc writes are blocking, so you can end up with stacking events...

But value change events just get added to the queue for the tag which then get processed in order (I assume?), no? From the value change event scripts that are currently running, they don't care how long they take*, their code will always run from start to finish.

*should be as fast as possible, but running too long may simply cause new events to be dropped; however the value change events that are running don't care, they just keep running until they've finished

well yeah, but then you aren't guaranteed any sort of timing on when those writes are going to fire, even if you do have a guarantee as to order

Not true, because there is a Thread pool across the gateway of size three (by default), so only 3 value change events can ever be processing at one time. This is seperate from the event queue specific to each tag (size 5 by default).

1 Like