Hello there, I'm new to using node red and I am wondering if it's possible to read a value off of an excel spreadsheet and use it as a variable on a PLC. The project is to clock times for workers on how long they take. I want to be able to set a schedule on an excel spreadsheet and have the schedule load on the plc with which I will then eliminate values from the schedule as things are finished.
Yes, but you have to run nodes7 library instead of available nodes
examples can be found: Siemens reading from PLC with nodeS7 npm
This is a lot of help thank you, I'm now using the nodes7 library, do you think it's possible to send information from your software back to the PLC, I see in your example you are using read values, but I still need to give feedback from the database and have the PLC read the value and adjust a schedule.
Hi, here you're discussing two very different things:
-
For loading the excel values into node-red, I'd say just save the file as .CSV (pure comma-separated text), read it and parse it to turn it into a JSON. The easiest way is using the default csv node.
-
Bring the parsed data into the Siemens PLC. As long as it is Step-7, you shouldn't have problems if you're using the node-red-contrib-s7. I would recommend this over the NodeS7, since I've been using it in production for years without any big issues. Reading is a breeze, and you can do it one variable at a time, or all at the same time. Configuration can be done by adding the variables one by one in the node, or you can import a text file with all the variable names you want to read, their type and address. As long as the PLC endpoint has the read/write variables configured, writing back to it is as straightforward as passing 2 arrays to the s7-write node, one with the variable names you want to write (the ones you configured on the endpoint), and the other one with the values you want to write (with matching indexes). It just works, and saves you the time of having to remember the addresses.
It is very straightforward, honestly. Give it a try.
Agree with you.
I automatically assumed that variables need to be dynamically defined and read. If variables are non changing at PLC end, then existing S7 node is a way to go.
It would be VERY dangerous to dynamically alter the variables and addresses outside the PLC.
The usual way is to define static, non-optimised blocks with fixed addresses and offsets, configure the endpoint with all the names and addresses, then you can use the s7 node to read or write variables by name dynamically, one by one or in batches, but from those you already configured on the endpoint.
It is the safest and most reliable way.
There are some use cases where this is just not possible.
My use case:
I have a field with 30 PLC. Each PLC is different because automation layout is different. What unites them is that data structures are the same. Let's say PLC1 has moduleNames 1,5,6,7,10 with DBs assigned to them 101, 105,106,107,110. They are identical with structure.
Another PLC will have modules 1,2,3,4,8,9,10 with DB 101,...,108,109,110.
What is the restriction for contrib-nodes7 is that once you point into non existing area, you will get BAD255 for all existing ones. And I'm speaking about 1000s of Tags.
Now you could define different endpoints for all PLCs and import as CSV files. But I found it faster to dynamically define addresses and iterate though whole field with single node than creating multiple endpoints and maintaining excel scripts which would help me to generate those variables.
I am handling dozens of S7 machines. I have a csv file for each model, and I import each one of them. It's only needed once, when you configure the endpoint.
The other option is to enable a byte array as a buffer between NR and the PLCs and you just transfer the whole buffer in one go, but then you have to decrypt the buffer in the PLC and assign the values to each tag.
In any case, having dynamic indexing from the outside is, as I said, a very bad idea, specially when writing to the PLC. If you make a mistake you can overwrite things you shouldn't have.
PLCs are supposed to be focused on reliability first, so it is a good idea to make things as stable and reliable as possible.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
