PLC 5/20 RIO Addresses

[DavidSr]

Good Afternoon,

Advanced HMI indicators configured to read I/O from a remote chassis do not work. I have to add bit addresses to be read so for every Remote I/O address I want to read, I have to add bit file address so when for example I want to monitor O:030/01, I have to put B3:1/2 in parallel with it and read that from ADHMI. I cannot read the remote I/o directly .

David

[Archie]

Reading physical IO is a known issue with the latest version and should be fixed before 3.99y is taken out of Beta

[Phrog30]

I recommend you have AdvancedHMI read the entire word, then break it apart to read each bit.

[DavidSr]

Thanks both of you, I am not having difficulty with Local I/O though, Only Remote.

Another issue I was having with RIO was the HMI crashing when I configured one but I have avoided reading it directly so I would have to try to duplicate the issue before I ask for support on it....

A question for Phrog though.. Why go to the trouble of reading the entire word and selecting the bit I want when it is simpler to just use a bit?  You must have reason for doing that.. PLC Memory us not an issue.

Thank you!   

.... and Archie, I cannot thank you enough for all of this work you are doing and giving it away. Not very common.

David

[Archie]

I don't have a setup with remote IO, so I am not able to test it. I can't imagine where the difference would be. I think the issue with reading the normal IO is when you use more than 1 address from the same card. Could that be what you are seeing with the remote IO?

[DavidSr]

 I am trying to read more than one Input from the same and different remote and local, I will have to check what issues I am having and see if I had to use bit file addresses in the local anywhere, It has been a while since I did this so I will have take a look in the next couple days and get back to you on specific things I did to read both local and remote i/o

 I am planning on purchasing your application upgrade service soon. When are you releasing a new version?

  Thank you..

David

I don't have a setup with remote IO, so I am not able to test it. I can't imagine where the difference would be. I think the issue with reading the normal IO is when you use more than 1 address from the same card. Could that be what you are seeing with the remote IO?

[Phrog30]

A question for Phrog though.. Why go to the trouble of reading the entire word and selecting the bit I want when it is simpler to just use a bit?  You must have reason for doing that.. PLC Memory us not an issue.

I guess it depends on what you are doing with the bits.  I've been using Ignition a lot lately, which is super simple to do this, it's a little bit harder to do in AHMI, so I think my mind wasn't thinking platform specific.  But, an example, even in AHMI, if I was to create a graphic that showed the PLC card IO status, I would read the word and then break apart the bits for each channel.  I do that in alarms as well.  It's more efficient to read 10 words, then 10*16 or 10*32 BOOLs.  But, do what ever is easiest and makes more sense to you.

[DavidSr]

I guess it depends on what you are doing with the bits.  I've been using Ignition a lot lately, which is super simple to do this, it's a little bit harder to do in AHMI, so I think my mind wasn't thinking platform specific.  But, an example, even in AHMI, if I was to create a graphic that showed the PLC card IO status, I would read the word and then break apart the bits for each channel.  I do that in alarms as well.  It's more efficient to read 10 words, then 10*16 or 10*32 BOOLs.  But, do what ever is easiest and makes more sense to you.

I get that.. I put all alarm bits in a bit file ( usually B13) and monitor the value of the entire file, if all the words add up to more than "ZERO" i set an alarm output and read which bit is set to send to the HMI to display the appropriate alarm message. For a reset- I use a fll to fill the file with zeros, if an alarm is still present it will write a one back to the file for the alarm. I am sure there are other ways and maybe better to do that.  There are much better PLC programmers than me out there but I manage to get the job done.

For some things I want to read the actual status of the physical inputs. After re-checking the system. I am not having issues reading physical inputs on the local chassis, Only the remote.

[Phrog30]

It really is best practice to not use physical IO for an HMI.  I always map, I started doing that years ago.  If you do a lot of work as an integrator it will save time in the long run (end users - maybe not so much).  I might do one project in CpLX, the next CLX.  If I map, I simply change the mapping file, the rest is the same.  If I used physical IO or alias, I would have a bunch of errors and things to fix.

A suggestion on the way you explained alarming, I would do a buffer.  The HMI would read the buffer.  That way the HMI won't "pick up" the occasional clearing and setting.  Even with a slow poll rate, the HMI will eventually see the change.  The buffer is always the actual result.  Just my two pennies.

Not sure if you read Archie's comments, but it is a known issue for reading physical IO, regardless of local or remote.  So, for now you will have to use mapping.

[DavidSr]

You are right- And I always use bits triggered by I/o for the reason you stated and in fact although it is allowed, I never ever use a physical address twice in a program, I set up control bits. That way if you have to change something in hardware you don't have to hunt all through the program and make changes.

I have done what you do for alarming in an HMI--- , man I have not been doing this for a living for quite some time so I have forgotten how I used to do things. Your post refreshed my memory...   

What I am doing now is a home project with some PLC stuff I have accumulated over the years.