simple question rslogix alias tags

[rdrast]

What is your problem with understanding asynchronous IO scanning?

With asynchronous scanning, the IO is updated periodically based on its RPI setting. That's it. Nothing else comes into play. A single IO point could potentially be updated (and changed) several times during the scan of a particularly long program routine.

With synchronous IO scanning, the processor (generically, different manufacturers may change the sequence) Scans the inputs, processes the user program, updates the outputs, and repeats.

 

[bce123]

What is your problem with understanding asynchronous IO scanning?

rdrast, None! . It is how to use this in logic and how to avoid its down falls and take advantage of its that I want to under better. For example I believe that I can Write to an alias bit from a hmi its just a matter of timing this in the program. I could be WRONG I have been it the past however I will learn something from trying And this is what its about.
Best regards, Steve

 

[rdrast]

In short, never try to write to a physical I/O point, alias or not. As mentioned before, the alias is still the exact same point, just named.

Some platforms will flat out refuse writes to the I/O area, some will seem to accept them, but won't in reality. Even if such a thing were possible, it would be impossible for you to synchronize the comms timing of your HMI vs. the IO Update scan to achieve anything meaningful.

 

[bce123]

OK I here you!!
however I am still going to experiment with this using the hold time option for a momentary push button on the panelview. In my mind (limited) I should be able to make this work by knowing the scan time of the ladder as long as the hold time is greater than this I think it will work, it may not, I don't really care I just want to know for sure either way again at this point it is just an experiment. I am waiting on a 1769 ecr so i can add some I/O to check this I will update latter. Has anyone tried this in real life?
Best regards, Steve

 

[daba]

OK I here you!!
however I am still going to experiment with this using the hold time option for a momentary push button on the panelview. In my mind (limited) I should be able to make this work by knowing the scan time of the ladder as long as the hold time is greater than this I think it will work, it may not, I don't really care I just want to know for sure either way again at this point it is just an experiment. I am waiting on a 1769 ecr so i can add some I/O to check this I will update latter. Has anyone tried this in real life?
Best regards, Steve

Don't bother !!!

Hold time or not, the HMI access to the tag is a brief "write".

For a momentary pushbutton it will write a 1 when pressed, and a 0 when released.

Note that is TWO writes, one to send a "1", and one to send a "0" - you cannot "force" the input tag to be a "1" by using a hold function on the HMI

Extending the time with a "hold" timer just simulates a person holding the button longer.

And this has absolutely NOTHING to do with SCAN TIME - the input tag will be changing at the RPI of the input module, so can (and most likely will) undermine your attempt at capturing the HMI data, which was written, and forgotten about.

Communication of data is not like hard-wiring, the HMI cannot keep that tag true.

How else can I say it to persuade you?

 

[bce123]

How else can I say it to persuade you?

OK that makes since!!!
so if i change the RPI of the Flex I/O (can I even do that?)what would happen?
Its not like I'm committing suicide here, its just human nature to try and do what they say cant be done. If it doesn't work I learn just as must as if it did.
Best regards, Steve

 

[daba]

Changing the RPI of your I/O update will not help your problem.

Since the I/O is Asynchronous to you program scan, and the write from the HMI can occur at any time, you will inevitably have the HMI write its "1" to the tag microseconds before the I/O update puts it back to "0" again, and of course your program code will not see the "1" in the tag.

You will be creating a situation where the HMI input will work, at best, most of the time only, you will never, ever, get it 100%. So the operators will be pressing HMI buttons, expecting something to happen, which it won't.

The only way to do this properly is to "parallel" the inputs with the HMI data.

This may not be as onerous as it seems, because you can of course do 16-bits at a time by locating the HMI bits in the same pattern as each input word, and using OR instructions.

 

[bce123]

Changing the RPI of your I/O update will not help your problem.

The only way to do this properly is to " "parallel" the inputs with the HMI data.

daba, Thanks
I assure you I have no Problem. I have already added the 123 controller tags to do this and inserted them in parallel to the real world inputs and I am not playing around with the control net scheduling on this system I will be installing the panelview this A.M. I am just doing this experiment on the bench to better understand the relation of the I/O scan to the program scan times and what is the usefulness of the separate updates if you cant time these events in your program. The original idea was a result of too many long 18 hour days and trying to find easier faster ways to work. I have had a few hours sleep since then. I appreciate all the help here and do not take the advice of folks MUCH smarter than I lightly. These test are just a way of drilling this in my tired brain.
Best regards, Steve

 

[daba]

OK, go ahead and do your tests if it helps you to understand....

... but please don't make your test PLC program so short that it scans very quickly, or you will probably find that you press the HMI button 100 times and it will work 100 times. Then you might think you've cracked it and all the advice you've received is wrong.

Even with a short PLC scan time, it will fail eventually, you just decrease the chance of failure with a shorter scan time. The longer the PLC scan time, the more possibility the I/O update has restored the tag before the logic sees it.

 

[bce123]

OK, go ahead and do your tests if it helps you to understand....

That is the Idea!!

please don't make your test PLC program so short that it scans very quickly

Thought about that already. I will add some sub routines and such. However It should be some what related to the amount of real I/O to program scan time I think?
Best regards, Steve