Node-red-contrib-netvar - negative "REAL" Type PLC values arrive in node-red as null

General
1

Hi there,

I was testing node-red on my Wago PFC200 (as a container in docker) and to do so I created a sinus function in my PLC with data type REAL.
The node netvar-receiver can read my variable, however when the variable is negative the node returns "NULL".
Under is the result of 2 variables (polling with 2 seconds interval). array 0 is the sinus function in REAL; array 1 is the same function in INT:
{"0":["r_Temp","REAL",null],"1":["i_Temp","INT",-6]}
{"0":["r_Temp","REAL",10.24],"1":["i_Temp","INT",10]}

Any idea how to fix this issue?

2

Sounds like a problem with that netvar-receiver node. You would likely need to collect relevant info (like nodejs, node-red, netvar-receiver version numbers) & a couple of screen shots - and raise an issue on the developers github "issues" page.

To be sure, can you show a screen shot of your flow and your PLC value taken at the same time?

Just to be sure there is no processing occuring in node-red that is affecting the value.

3

Hi,

Thank for your quick answer. Here is the code:
[
{
"id": "33759c28.55d4c",
"type": "netvar-receiver",
"z": "8c4f3e22.59c16",
"index": "1",
"vars": "r_Temp:REAL;i_Temp:INT;",
"x": 320,
"y": 140,
"wires": [
[
"9f0384f5.be2628",
"a6ecf90f.29aee8"
]
]
}
]

Attached video for flow and PLC value taken at the same time.

2020-05-24_12h30_09
2020-05-24_12h30_091904×986 2 MB

4

does look to be an issue with the netvar-receiver node.

Unfortunately, the npm node doesnt link to a repository & I cant find the source in github or gitlab.

Also the readme states "Not for production use. See LICENSE file."

So you have options...

  1. modify the nodes source and fix the issue (likely a simple bug)
  2. use modbus or better still, another protocol the PLC supports (ideally, this PLC would support MQTT and the complexity of this will shrink to pretty much zero)

EDIT...
To make code more readable and importable it is important to post it between two sets of three backticks - ``` - see this post for more details - How to share code or flow json

EDIT2...

  • does the node have other options to INT and REAL (like FLOAT or SFLOAT or SREAL)?
  • does the PLC have FLOAT type or other similar types you could try?

EDIT3...
In situations like this - I avoid FLOAT/REAL altogether and simply scale up the value in the PLC.
for example if I am expecting a value between 0 ~ 9.999 I will use a 16 bit UINT of 0 ~ 9999 and then scale it at the other end.

5

Hi Steve,

Thanks for your tips. I try once more with backticks:

[
    {
        "id": "5074aea9.b8b434",
        "type": "udp in",
        "z": "8c4f3e22.59c16",
        "name": "",
        "iface": "",
        "port": "1202",
        "ipv": "udp4",
        "multicast": "false",
        "group": "",
        "datatype": "buffer",
        "x": 140,
        "y": 140,
        "wires": [
            [
                "33759c28.55d4c"
            ]
        ]
    },
    {
        "id": "33759c28.55d4c",
        "type": "netvar-receiver",
        "z": "8c4f3e22.59c16",
        "index": "1",
        "vars": "r_Temp:REAL;i_Temp:INT;",
        "x": 320,
        "y": 140,
        "wires": [
            [
                "9f0384f5.be2628",
                "a6ecf90f.29aee8"
            ]
        ]
    },
    {
        "id": "a6ecf90f.29aee8",
        "type": "debug",
        "z": "8c4f3e22.59c16",
        "name": "",
        "active": false,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "payload",
        "targetType": "msg",
        "x": 530,
        "y": 220,
        "wires": []
    }
]

Regarding your options:

  1. I'm a newbea in Node RED and don't know how to modify the node source. Can you redirect me to a tutorial?
  2. I'll try with Modbus TCP or OPC UA which are released for production purposes.
  3. The node doesn't support FLOAT or SREAL. I've tried with no success.
  4. I'd prefered not to scale because the purpose is to push the variable to an IoT Application Enablement Platform (AEP), such as Ubidots.
6

Are you sending the value PLC --> node-red --> AEP?

then there is zero reason you cannot...

PLC --> node-red ( range node to scale value) --> AEP.

that is the beauty of node-red.

Not per-se - learn JS and read the source in the .node-red/node_modules/node-red-contrib-netvar folder. you will likely see some code trying (and failing) to convert a REAL number from several bytes.

Another way you can handle this is to read the data as a series of bytes & do the conversion in node-red.

MQTT will be FAR simpler and FAR more stable (in my experience) - ask if you want details on that statement!

7

Hi Steve,

As I precised above, I'm quite new to IoT world and make discoveries every day in this field.
I would be very interested if you can give me further details on your last statement. I don't know if this is the place to discuss about that or send PM?

8

Here is fine.

so, I have used all of the above mentioned protocols (for years) and in my experience, in node-red (and general IoT), MQTT is simply the best medium. OPCUA is a BEAST (read the spec if you have a spare year). Its complex and heavy. dont get me wrong, OPCUA is a tremendous and detailed specification but if you want to get a simple value from A to b and you have MQTT at your disposal - chose that. every time!.

As for modbus - the nodes avaiable for node-red work for the most - but a quick search of this forum will reveal how much people A struggle with it and B how it can crash node-red (not good!)

Are you familiar with MQTT?

If not - read this

In fact, give it ago - it will take you 5 minutes.

Lastly...

I would strongly urge you to watch this playlist: Node-RED Essentials. It is by the developers of node-red. They're nice & short and to the point. You will understand a whole lot more in less than an hour. A small investment for a lot of gain.

9

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.