Msg.payload return String with numerous symbols

General
1

Hi !

I am pretty sure this a stupid question, but I can't get over it !!

I've done a simple node which consist in reading a value from an OPC UA server (Schneider M241 PLC). But the message returned is filled of symbols. Also, when I change the value of the string for a shorter one, the remaining characters of the older value stays in place (ie: OLD=ABC123, NEW=XYZ then msg.payload=XYZ123).

image
image.png1695Ă—95 11.7 KB

2

Believe me what I assure you the only dumb question is the one you don't ask.

I'm good at asking questions.

Looking at what you posted - and I am not an expert - I think your data is formatted as JSON.

Put a JSON node between the OPC UA (the right most blue one) and the debug node.

See if that helps.

Another thing is to actually put TWO debug nodes there.

Why?

Well, by default the debug node shows you ONLY the msg.payload.
But it can show you EVERYTHING as well.

So?

Well, if I am correct and the data is a JSON format: it is structured differently to normal. Be it there is such a thing.

Usually you get something like:
msg.payload = "This is the payload"
msg.topic = "This is the topic"
msg.colour = "blue"
msg.time = "12:22:18"
msg.date = "24 April 2019"
msg. (and so on)

You can make a lot of stuff in a message.

Just usually it is only the payload which is of importance.

Yeah, so?

Well, sometimes, when you have to send a message over a protocol - say MQTT, which is a well used protocol in NR - you only can send the msg.payload and msg.topic.

I may not be 100% correct, but I am explaining what is going on.

So: those nodes are sending all their data in a JSON packet/encoding.
This allows all the other stuff to go thorough something like MQTT.

Therefore you put it through a JSON node and look at it with a DEBUG node and you will see it all "taken apart" and in a format which is like I explained with the msg.colour etc.

Double click on the debug node and select complete message object.
Then when something comes in, you click on the little > symbol and expand that part of the message and you will see all the sub-components.

I hope that helps.

And again: I am not an expert.

1 Like
3

That sounds as if the string you are sending back does not have any indication of where the end of the string is, so it is getting a buffer full of data where the end portion is whatever was lying about in memory, or in the second case the end of the message you put there the first time.

1 Like
4

I don't know enough about opcua or plc in general... but as Colin says it looks like it's just reading back one "chunk" of data. Not sure if you need to terminate the string when you write it in the first place, or if the plc should do that for you, or if you can set it to read only a certain number of characters, etc. For example strings in C are often terminated by the 0x00 character. You may need to read up on your plc some more to work out what is really needed.

5

Null (0x0) terminate your string in the PLC.

Typically, this is achieved by either using STRING type functions to write the string in memory or appending a zero value byte after the last character.

6

Thanks everyone on helping me ! It helped to resolve my problem.

The reason of my problem:
In my PLC the STRING have defined length. So, node-red, fill the "empty" parts of the string with all those symbols.

What I did to resolve:
In the PLC code, I filled the string with a symbol that in my case should never have to be used. Then I remove this symbol with a string node.

I do not know if it the most elegant way to solve it, but it worked!

7

Why not use null, as suggested by others?

8

I didn't figured out how to use it in the PLC