Controlnet Tag Issue

I'm having an issue with a set of Produced / Consumed tags that I can't seem to figure out. I keep getting the error code 16#031f, Connection Request Error : Tag Not Published. I've deleted the tags from the producer and the consumer, rescheduled connections numerous times, but I can't clear it. Any suggestions appreciated...

16#031f
Cannot consume tag.
No SC (servicing controller) connection object was found that corresponds to a symbol instance.

Did you produce the tag correctly? Does the tag name match on produced and consume plcs?

Jim3846 said:

16#031f
Cannot consume tag.
No SC (servicing controller) connection object was found that corresponds to a symbol instance.

Did you produce the tag correctly? Does the tag name match on produced and consume plcs?

Click to expand...

Thanks Jim, yes, it was actually one of my students, the tag names were correct, however, he pointed to the wrong tag in the tag connections...

I completely missed it.
Thanks again for your reply.

I always do this tag names dont exactly match between processors. Even caps versus lower case matter. painful memories.

I used to tell students to copy the tag name from the Producer and paste that into the Consume tag connection. Invariably when we type, we miss something.

OG

At my first job in this field, the systems integrator at the plant was showing me how to work with Wonderware. Everything mapped to the HMI was comes from just a handful of tags (arrays) that were:

• H_Ind[x]
• H_Alm[x]
• H_Cmd[x]
• etc

So I'm told, if you have to add a button, find the next available H_cmd[x] to address it to. If you need to add an alarm, find the next available H_Alm[x], same as everything else, but for alarms, you must copy/paste H_Alm[x] from the PLC, there is a bug in Wonderware, you can't type H_Alm, it won't accept it.

I says to myself: Self, that doesn't sound right.

So everyone at the plant that has to work on the HMI's does this. copy/paste H_Alm from the PLC.

"Are you sure that your lower case [ell] is not actually an uppercase [eye]?"

It sure was. Ding-dongs named the tag H_AIm thinking that it was H_Alm.

This wonderware instance interfaced with 8 ContorlLogix controllers with with an average of 6 remote 17 slot racks each. The amount of energy that went into that one single typo was laughable. On initial testing, someone scratched their head for a while when none of the alarms would work. Then when they realized that if they copy/pasted the text from the PLC they would work, for some strange reason. So instead of checking the spelling, copy/pasted 500 H_AIm[x] tag names, one at a time. And continued to do it as they commissioned the plant.

Makes total sense, yes? Copy/Paste. I can't tell you how many times one of their MSG instructions doesn't work because of an output being typed 4:0 instead of 4:O... I tell them that's why the other guys use Q!

I use to work for Big Oil, programming process simulations in Fortran.

One day I chased down a typo: H20 (H-twenty) instead of H2O (H-two-oh). H2O (H-two-oh) was an constant INTEGER PARAMETER index into the component fractions that made up a stream (the rest were CH4, C2H6, etc.). H-twenty on the other hand was parsed with a glad cry by the compiler and, because it started with H, and not with I-N, it was assigned memory as a REAL and initialized to zero. Fortunately, subscript checking was turned on by default in the compiler, so as soon as the code ran and it tried to access the water component fraction FRAC[H20] of a modeled stream, the code crashed, because FRAC was an array and the only valid indices were 1 and up, i.e. FRAC[1], FRAC[2], FRAC[H2O], etc., were valid, but FRAC[H20] => FRAC[INT(0.0)] was not. Side note: this is where I learned about the desirability of the IMPLICIT NONE statement.

Just for curiosity, I did a global search of all Fortran files on the system, searching for H20 (H-twenty). The only matches I found were by the team doing a huge project involving a series of simulations, taking up 50% of the CPU 24/7, modeling a pressure balance on a pipeline: they had turned off subscript checking to make their code run faster.

Hence the translation part of FORTRAN!