Ignition Vision Text Field Input Not Updating PLC Tag (Version 8.148)

Ignition
, ,
1

I'm having an issue that I'm pretty sure is down to an incorrect setting on my end. I'm hoping someone out there has seen it, before. Using Text Field inputs, I'm seemingly unable to get the PLC to update the tag value without adding some scripting tag value update functionality.

I'm using a Schneider M580 PLC.

The tag in question "Customer_Name" is set as a 32 bit string within the PLC. It is set as an HMI variable to allow the screen/Ignition access to it. It is used nowhere within the PLC's code [value is stored in the PLC for the sake of data retention/recovery].

This is not the only tag I'm having this issue with, but it's the easiest to diagnose with because it's referenced nowhere within the PLC code, so -I would think- there's no chance of it being overwritten after the screen changes it. The other tags are all strings as well.

If I attempt to update a string memory tag within Ignition, it functions as intended.

Numeric entries are used to update PLC tags, and they work as intended.

As far as I can tell, the write permissions are correct, the text field is set to bidirectional, and the fallback delay has been tried at both the standard 2.5 and an extreme of 60, just in case it was a communication delay. Screenshots are included for tag properties and text field properties. All of the threads I found on this forum regarding this issue seem to have been solved by these settings.

Updating the tag from the Vision Property Editor correctly updates the PLC's tag, but the quality seems to freeze on "Good_WritePending".

Any pointers would be greatly appreciated. As said, I assume it's something I'm overlooking, but I'm at a bit of a loss as to what it could be at this point. If there's any information that could be helpful that I didn't capture in the screenshots, just let me know, and I'll update.

Thanks in advance!

Reference Screenshots:

image
image1073×988 62.6 KB

image
image667×817 50.4 KB

image
image784×715 33.5 KB

image

2

Setting the logger called "vision.binding.tag-binding" to DEBUG might be useful.

image
image884×673 27.8 KB

(F4 to bring up diagnostics in Designer or Vision Client)

Look for logs in the Console tab.

3

The only logs showing up are referencing the IP Address display:
[component=Display_IPC_IP_Address,property=text] Tag [System]Client/Network/IPAddress changed, value=[xx.xxx.xxx.xxx, Good, Fri May 09 12:31:08 PDT 2025 (1746819068993)]

I'm not sure why this one's generating as the IP address isn't changing, and the address value in each log is the same, but I don't see that being directly related.

With the tag-binding set to DEBUG, I've tried a few times to change the text of the "Customer_Name" tag from the screen. Each time, it reverted to the initial value, and no logs were generated.

4

Can you write to this tag in the Tag Browser?

5

Yes. I have no issues doing that. It generates:
14:41:06.700 [AWT-EventQueue-0] DEBUG vision.binding.tag-binding -- [component=Text Field,property=text] Tag [Roaster_OPC]Troubleshooting/Customer_Name changed, value=[Test

Changing the value from within the Vision Property Editor generates:
14:42:04.963 [AWT-EventQueue-0] DEBUG vision.binding.tag-binding -- [component=Text Field,property=text] Property changed. Writing to tag. [Roaster_OPC]Troubleshooting/Customer_Name=Testing
14:42:04.964 [AWT-EventQueue-0] DEBUG vision.binding.tag-binding -- [component=Text Field,property=text] Storing previous value for fallback: [Test, Good, Fri Sep 06 01:06:00 PDT 2024 (1725609960737)]
14:42:04.965 [AWT-EventQueue-0] DEBUG vision.binding.tag-binding -- [component=Text Field,property=text] Write pending. [Roaster_OPC]Troubleshooting/Customer_Name=Testing
14:42:05.116 [AWT-EventQueue-0] DEBUG vision.binding.tag-binding -- [component=Text Field,property=text] Write op returned (current). com.inductiveautomation.factorypmi.application.binding.SimpleBoundTagAdapter$WriteOp@68a44709
14:42:05.118 [AWT-EventQueue-0] DEBUG vision.binding.tag-binding -- [component=Text Field,property=text] Fallback timer started, waiting for tag value update. (2500ms)
14:42:06.993 [AWT-EventQueue-0] DEBUG vision.binding.tag-binding -- [component=Text Field,property=text] Tag [Roaster_OPC]Troubleshooting/Customer_Name changed, value=[Testing, Good, Fri Sep 06 01:07:00 PDT 2024 (1725610020636)]
14:42:06.995 [AWT-EventQueue-0] DEBUG vision.binding.tag-binding -- [component=Text Field,property=text] Fallback timer canceled

6

Hmm, I don't know. Maybe support can look at it and figure something out.

I thought maybe it could be a problem with how the M580 OPC UA server does strings (or has done strings in the past), which is utterly broken. If you define the string as 32 bytes in the program, they will send the string value including as many null padding bytes as necessary to be 32 bytes. Ignition doesn't expect null bytes in strings nor can it render them, which causes some issues when you try to append text to an existing value in the tag browser as opposed to replace the value.

I thought maybe you were having an issue related to that, but I'm not sure now.

7

I may have been giving incomplete info on the logs, there. If I'm not mistaken, the logs pulled up from the designer will only cover the designer's session, not the client. [Client is running on a different computer.] I did not initially realize that. I'll try and get the console pulled up on the other computer in case it will offer any insight.

I'm glad you say that about the way the M580 handles strings...it makes me feel a bit more sane after some of the issues I've had to work around with string arrays.

8

yeah, you would need to pull up the diagnostics on the client.

9

Unfortunately, there's not a single reference in the logs of that tag being updated. [There's a good bit in there, but it's all related to a very incomplete popup screen that isn't being accessed during the current testing.]

I'll move on to support. I appreciate the effort!

10

Just to give resolution to the thread, the null character issue referenced here was the root cause. The solution ended up being to go through a derived tag with the trim() function to strip all of the null characters from the string.

2 Likes