I am using netvar-receiver from the node-red-contrib-netvar library (https://cdn.jsdelivr.net/npm/node-red-contrib-netvar@0.0.3/netvar-receiver.js), and one of the variables received (UDP on port 1202) is in a string format. Previously, I attempted to receive this string along with a bunch of ints and bools, but the string seemed to overwrite any variables received after the string. The easy solution was to put the string in the end, so it couldn't mess anything up. Now I am faced with the same issue once more, because I now need to receive TWO strings. Unsurprisingly, the first string replaces the second in the resulting payload.
Anyone with experience in this field?
Can you provide more information on what exactly is the symptom you are seeing, possibly debug node outputs showing the problem.
Also, so we can see what versions of node red and the support tools you are using start node red in a terminal and post the log you get here. Copy/paste rather than screenshot preferably. The log should contain the Welcome to node red message.
Node-RED version: 0.19.6
node-red-contrib-netvar version: 0.0.3
Netvar variable list:
DI0:BOOL;DI1:BOOL;DI2:BOOL;DI3:BOOL;AI0:WORD;AI1:WORD;AI2:WORD;AI3:WORD;AI4:WORD;AI5:WORD;AI6:WORD;AI7:WORD;UTC:STRING;GPRMC:STRING;
Debug node:
{"0":["DI0","BOOL",0],"1":["DI1","BOOL",0],"2":["DI2","BOOL",0],"3":["DI3","BOOL",0],"4":["AI0","WORD",3],"5":["AI1","WORD",3],"6":["AI2","WORD",3],"7":["AI3","WORD",3],"8":["AI4","WORD",3],"9":["AI5","WORD",3],"10":["AI6","WORD",3],"11":["AI7","WORD",3],"12":["UTC","STRING","1574068949569000000"],"13":["GPRMC","STRING","1574068949569000000"]}
Data is being received from a WAGO PLC, on which Node-RED is also running. In the PLC configuration, whichever of the two string variables comes first, this is the one being received as both the first and second string variable, though (as you can see) they are defined separately in the netvar variable list.
OK, so it is what is coming out of the netvar node that is wrong, I wasn't certain that was what you meant. Unless there is someone here with some knowledge of that node you would probably best to ask the node's author. Usually you would do that on the node's github page but there is not a link to that from the npm repository so that is not an option.
I believe that is the case, too. Experimenting in the meantime has proved that both strings are received in the UDP node (as ASCII), but after passing through the netvar-receiver, only one of them is left. The developer has been contacted, and we are trying to develop some kind of workaround until the issue has been fixed.
The code appears to expect the strings to be null terminated in the data coming in, are they null terminated in your data?
It appears not;
The converted ASCII data (array) looks like this:
-S3d([>1574079692806000000PFV dcgroup/c GPRMC,122132.00,A,1234.56789,N,12345.67890,E,0.013,,181119,,,D*77000*6D2,
Difficult to tell after it has been converted to ASCII, have a look at the raw buffer.
[0,45,83,51,0,0,0,0,1,0,0,0,14,0,202,0,19,162,0,0,0,0,0,0,3,0,3,0,3,0,3,0,3,0,3,0,3,0,3,0,49,53,55,52,48,55,57,54,57,50,56,48,54,48,48,48,48,48,48,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,80,70,86,32,1,0,0,99,103,114,111,117,112,47,99,32,0,0,0,0,0,0,0,0,0,0,0,0,71,80,82,77,67,44,49,50,50,49,51,50,46,48,48,44,65,44,52,52,52,52,46,50,48,56,48,53,44,78,44,48,48,52,52,52,46,50,55,51,50,51,44,69,44,48,46,48,49,51,44,44,49,56,49,49,49,57,44,44,44,68,42,55,55,13,0,13,0,48,48,48,42,54,68,13,0,50,44,0,0]
So are they null terminated?
Given that there are 0s all over the place, and 0 in ASCII corresponds to NULL, well, maybe. It seems that they are all over the place rather than only as line terminators, though.
Most of them are in the numbers I expect, which will have embedded zeros. Find an ascii table and find the strings in the buffer and see what is there. Presumably the strings are towards the end.
I am not sure that I follow. All the data received is listed above. The converted data is -S3d([>1574079692806000000PFV dcgroup/c GPRMC,122132.00,A,1234.56789,N,12345.67890,E,0.013,,181119,,,D*77000*6D2,
Looking at your ascii data which are the two strings you said are there? I can only see one D*77000*6D2
The two strings are 1) 13 characters of epoch timestamp and 2) everything from GPRMC and on. There are also a number of ints and bools inbetween.
Looking at the buffer the timestamp string appears to 19 characters (not 13) but is null terminated. The string at the end is also null terminated, so it doesn't appear to be that. I am not sure why I had to work that out for you.
Looking at the code
case "STRING" :
for (x = 0; x < 80; x++){
if (msg.payload[pointer+x] !== 0){
msg_temp = String.fromCharCode(msg.payload[pointer+x]);
tempstring = tempstring + msg_temp;
}else{
break;
}
}
data[i][2] = tempstring
pointer = pointer + 80;
break;
Notice the pointer = pointer + 80
It appears that the code expects there to be a fixed length string in there of 80 bytes, the end of the actual string being marked by a null, but there must still be 80 bytes in the incoming buffer.
I stand corrected; Yes, the timestamp at the beginning is 19 characters long, though the last 6 characters are useless zeros. I have noticed the pointer + 80 part as well, but I am not sure what can be done to prevent the problem, or at least not in Node-RED. We apparently need to experiment with the PLC's configuration to make it match the strict demands set in the node, unless the node is changed to support dynamic string lengths.
I know it's a late answer. But I will still post for the people searching for the same problem.
A standard string in a plc is 80 characters + 1 termination character. The pointer = pointer + 80 is wrong and should be + 81. Making the reading of the next string happens 1 character to soon. Because the last character is null, it reads an empty string for the second string. But the code also doesn't handels an empty string correctly and returns instead the last found string.
I created a new version of this node node-red-contrib-nvl that doesn't have this problem and parses your buffer correctly. See example flow:
[{"id":"47913433e00eb7f0","type":"inject","z":"7f84c2fbc12875d0","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"[0,45,83,51,0,0,0,0,1,0,0,0,14,0,202,0,19,162,0,0,0,0,0,0,3,0,3,0,3,0,3,0,3,0,3,0,3,0,3,0,49,53,55,52,48,55,57,54,57,50,56,48,54,48,48,48,48,48,48,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,80,70,86,32,1,0,0,99,103,114,111,117,112,47,99,32,0,0,0,0,0,0,0,0,0,0,0,0,71,80,82,77,67,44,49,50,50,49,51,50,46,48,48,44,65,44,52,52,52,52,46,50,48,56,48,53,44,78,44,48,48,52,52,52,46,50,55,51,50,51,44,69,44,48,46,48,49,51,44,44,49,56,49,49,49,57,44,44,44,68,42,55,55,13,0,13,0,48,48,48,42,54,68,13,0,50,44,0,0]","payloadType":"bin","x":630,"y":840,"wires":[["e40d76fa218a79c9"]]},{"id":"e40d76fa218a79c9","type":"nvl-receive","z":"7f84c2fbc12875d0","name":"","definition":"TYPE NVL:\nSTRUCT\nDI0:BOOL;DI1:BOOL;DI2:BOOL;DI3:BOOL;AI0:WORD;AI1:WORD;AI2:WORD;AI3:WORD;AI4:WORD;AI5:WORD;AI6:WORD;AI7:WORD;UTC:STRING;GPRMC:STRING;\nEND_STRUCT\nEND_TYPE","listId":"1","x":790,"y":840,"wires":[["0b115ae788e2bce3"]]},{"id":"0b115ae788e2bce3","type":"debug","z":"7f84c2fbc12875d0","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":960,"y":840,"wires":[]}]
1 Like
