TIA portal WinCC - I/O field not working

Hi,

I have now two times experienced that my I/O field is not working on the HMI that I have made.

I have several I/O field and some of the are simply not working to press on, the only thing I can do is to delete them and simply make them again. Further more it seems like if I copy this I/O field it also the same happens to the copy. I have copied alot of I/O fields and now many are not working. I have tried to rebuild. It also happens when I simulate the project. Any inputs?

/Tim

It sounds like they are set to output only. You can select this in the properties dialog box.

Do you mean you can't press on them to input a value? Do they output a value ok?

Are you compiling before downloading?

It does state that it does a compile as and when you hit the download button, maybe a bug I don't know. I've had several funny instances with downloading without compiling first.

Just a thought ...
Are you putting it underneath an object or overlapping by accident?

Rob... said:

Are you compiling before downloading?

It does state that it does a compile as and when you hit the download button, maybe a bug I don't know. I've had several funny instances with downloading without compiling first.

Click to expand...

Not just a regular compile, are you doing a Compile Rebuild All?



Officially, there's a note in the help file somewhere that you need to do a recompile all before you download to the HMI. I've definitely experienced changes that I've made that didn't work or only partially worked with only a regular compile.


I don't know what the exact issue is with the delta compiler, or what the point of it is, but the full compile always does the trick for me.

Other things to check, are you allowing operator control? Tickbox under security.

This can also be controlled dynamically under the animation field.

If it requires an elevated user to be logged in to use the input it will prompt a log in as default.

Thanks for all input, I have checked all this, but still not working. Only solution is to make new field. It does output the value but doesnt let me input. Very strange problem

JRW said:

Just a thought ...
Are you putting it underneath an object or overlapping by accident?

Click to expand...

The overlapping transparent object could be on a layer that is inactive when you edit the screen in WinCC, so one would look for it in vain. Not sure if the layer number takes precedence over the background/foreground levels.
Or the transparent object could be on the global screen or a template.

Texts that overlap sometimes surprise you. If the text size set to adapt to the text length, a text in your editing language may be much shorter than in one of the other languages, causing the text field to extend and overlap with some other screen objects.

It sounds like the Complining bug. There is an known (?) bug in the complier at least when working with Comfort or WinCC Unified HMIs.

I have experienced this bug since V10.. but it's just one of those things you get to live with.

How I first came across the bug:

We had a machine with some conveyors fans and other equipment. In the HMI we have a manual page for controlling the objects in the machine manually.

When I pressed Start Fan, a conveyor started. All the connections to the Pushbutton in the HMI were correct but long story short the compiler messes up the connection points.

I've also experienced this problem with I/O fields displaying temperature, pressure et.c


How to work with it:
1) Allways run a Compile all of the projects.
2) In the TIA project folder you have a map Called IM. Remove this map and run a compile all again.




Speaking of compiler bug. I have an old V12 project the accumulates the compiled data. Siemens have had looks at it but can't understand why it's acting the way it do. That project file is for a small Robot cell but the project data as of today is over 4gig big.

Thanks once again for the inputs, but it is just a normal I/O field, nothing more nothing less. All settings are normal.

I have tried the VictorBit solution but it doesn't work.

/Tim

I have now found the problem and solution.

I have a rectangle with the background "transparent" and only used the lines to box in my settings. When moving the rectangle to the back, all settings worked. And also if I add a new I/O field this is inserted as the most forward object.

Who would've thought that a transparent rectangle is still "active" as a whole. When making a button transparent it is shown as a dotted fill layer.

/Tim

Yep. Post 4
If you read it

PLC said:

Yep. Post 4
If you read it

Click to expand...

Sure, but since it is an transparent object I don't see it as I should affect anything. Also since it doesn't show as dotted fill

rQx said:

Sure, but since it is an transparent object I don't see it as I should affect anything. Also since it doesn't show as dotted fill

Click to expand...

Should? Dunno. Makes sense to me that the object on the top of the stack is the one it tries to interact with, unless the system does a lot of work to try to guess what the user really wants.

Dotted fill makes sense for invisible buttons because they are still clickable in that area. Transparent fill, border only, rectangle show up exactly as you configured them.

I mean, I'm not saying that it's IDEAL, but there's certainly a direction from which the logic makes sense. Just remember that the core runtime of the Comfort Panels was developed at least 15 years ago, and everything else is layered on top after the fact. It's why Siemens is making such a big deal out of the Unified stuff, despite the fact that the usability is currently Mud. It's the first time they'd had a mass market HMI with new tech in a long long time.

mk42 said:

Should? Dunno. Makes sense to me that the object on the top of the stack is the one it tries to interact with, unless the system does a lot of work to try to guess what the user really wants.

Dotted fill makes sense for invisible buttons because they are still clickable in that area. Transparent fill, border only, rectangle show up exactly as you configured them.

I mean, I'm not saying that it's IDEAL, but there's certainly a direction from which the logic makes sense. Just remember that the core runtime of the Comfort Panels was developed at least 15 years ago, and everything else is layered on top after the fact. It's why Siemens is making such a big deal out of the Unified stuff, despite the fact that the usability is currently Mud. It's the first time they'd had a mass market HMI with new tech in a long long time.

Click to expand...

I guess I interpret the "transparent" as "invisible". It does make sense in a way but not in another way. If I only want a border, why would I wan't the transparent fill to "be" something that can be on top of something?

Guess you can see it many ways, good thing is that I'm aware now