Panelview Component C400 communicating with SLC503

[CeeDee]

Wow, it's been awhile since I've been on here. But, I'm so glad this forum exists.

I know, no one really likes the AB panelview component HMIs, but I'm stuck with them. I purchased them for work to replace panelview 300 micros awhile back and I'm just now getting back to this project. I've searched on here and on google and found a thick manual I'm thumbing through now. So, I thought I'd throw this query up now in the meantime to see if someone knows exactly what I'm doing wrong.

Panelview
2711C-T4T

SLC503 CPU 1747-L533E
Chan.0 (RSR232 port) configured for DH485


I'm having communicating problems after trying to validate program. Particularly warning error 3015. It seems like no one is home on the RS232 port on the C400. Because the chan 0/RS232 port on the SLC CPU communicates fine when I use it to link up in RSLinx and download programs. I'm using the on-board programming via Ethernet and web browser for the C400. It's a little slow, but works. I have a very simple program written for the HMI and the SLC, a couple onscreen buttons and indicators showing the status of the buttons, just to prove proper communication.

Within the HMI web browser program once in the edit mode, under the "communications" tab I've selected DH485 protocol. "Driver" section PV comp settings, it has a pull down for "port name" and has only two choices "DHX1" and "DHX2" I'm not familiar with these. What are these for? I have the node for the SLC set for 1 and the C400 set for node 2. Controller name matches the processor name I gave it under "controller properties" within RSlogix. My tags are under the "external tab" and addressed like I used to do using panelbuilder32 and using the tag editor.

Ummm... yeah. Any ideas what I could check?

Thanks guys.

 

[CeeDee]

Ok, I was able to get it working after some Dinking around. I might have had my nodes mixed up on the SLC side. But also verified within panel view explorer communication tab.

But, now I can't seem to get a couple of multistate indicators to work. They are tagged to "O:3.0/0" and "O:3.0/1" just to show an on or off status on the HMI. I have the data type set to boolean. I can trigger those relay outputs with a couple of touchscreen buttons, no problem. I can see and hear them trigger right off the output card. I just can't get that status to show up on the screen.
It could have something to do with the validation warning ID 3015: "tag sw1 output with address O:3.0/0 has either an unknown address, unacceptable data type or undefined controller name" ... There's one more warning with sw2 that says pretty much the same thing.
I don't get it. It has to be addressed right or it wouldn't be working as it is. Any ideas?

 

[Mickey]

I am not a Panelview Component C400 user.

It is quite possible that an output data type cannot be read directly. Try moving the output word to a binary word then read the binary bit with your HMI.

I would not write directly to a output address, write to a binary address then let the controller control the outputs. It just good practice.

 

[Geospark]

The I/O addresses can be accessed directly but it is indeed good practice to map them to binary file addresses first.

If you want to persist...

For that warning ID 3015, instead of using...

O:3.0/0

...try using...

O0:3/0

Regards,
George

 

[CeeDee]

I believe I got that issue figured out. You are right, this program for some reason doesn't like Input or Output addresses in the tag editor. As soon as I changed them to bits, added a couple rungs in the ladder program for those bits to be controlled by the outputs I wanted, it worked. I don't get it. I am able to use input and output addresses on the older panel view 600 standard program: panelbuilder32 with no problems. I only use them to see simple on/off statuses for a motor-contactor or valve. I didn't know using bits exclusively (versus I/O adresses) for the HMI was good practice. Hmmm....

Thanks again for chiming in~!

 

[Geospark]

So you didn't get to try that addressing option?

It does "like" them. It's just it can be fussy with their addressing syntax. It has to do with CCW's programming under the hood. It is much different to the older PanelBuilder32 software. So they are not really that comparable.

You mentioned adding rungs to set the binary bits off the outputs. Another widely used practice for HMI piggybacked signals is to use B or N addresses and simply parallel an OTE off the Output OTE on the same rung. The same preconditions will set the HMI signal as the actual Output.

But using separate rungs is fine too.

Regards,
George

 

[Mickey]

Its ok to read input/output addresses, if the HMI software allows it.

The bad practice (IMHO) is trying to write to the input/output addresses.

 

[gbeaker]

You need to treat every 16bits as another word.

Example:

I:1.0 0-15
I:1.1 0-15
I:2.0 0-15
I:3.0 0-15

I:3.0 will need to be referenced in PVC as I:4.0 since it is the 4th word.

 

[CeeDee]

Geospark - I like the ideas. I forgot to try them today. After I got things to work, I started on working on other bugs and "things to do" with this program. I started, messing with the alarm list and getting that to display correctly on such a small screen was a pain. I got lost and ran of time today trying to get a date and time to display on the HMI so the user can reference alarms from the HMI and not their watch (if they even have one). I thought it would be a simple drag and drop much like the panelbuilder32 was... nope!
I will make a note to try your addressing idea when I'm back to work after the weekend. Anything would help so I don't have to go back into the ladder and add all those parallel OTEs (another great idea). It wouldn't be that hard, just more work.

It's always hard to see past "your" way, since you're so used to doing things that way. It's hard for me who doesn't do this all the time to visualize a better way to do something until someone shows you. As soon as you mentioned piggyback and parallel OTEs, I thought how brilliantly simple, duh! Might even make it easier to troubleshoot scrolling down the program.

gbeaker - I'm not following I:3.0 in of itself, to me, usually calls for an analog input. My normal addressing for discrete DC sink 16 bit input is, for example, I:1/0 which is for input card slot 1, bit 0. Which is the same as saying I:1.0/0 or... do you mean something like this: I:2/8 = I:2/40 ...??

 

[gbeaker]

CeeDee,

You need to count every row in the data table as a separate slot.

Even though you want to reference I:2/0, if it happens to be the 3rd or 4th row in the data table instead of the second row, you need to reference it as I:3/0 or I:4/0.

The PLC still knows this as I:2/0 but the PanelView Component does not.

Confusing? Yes. But that's AB.