I am curious about an assumption about how a Digital Input Module works. I have several EPIC systems in the facility with one being used to generate a groov View display in the Operations Control Center. My assumption is that a Node-RED I/O input node that waits for a change in a remote EPIC/module/tag would use a lot of network bandwidth. To eliminate this bandwidth, I set up a node in the remote EPIC to send the tag change to the Control Center EPIC Data Store. On the Control Center EPIC I use a Read Node to monitor the Data Store tag, wait for a change, and respond accordingly.
Is this food practice?
Thanks for your help.
Depends on if you really need to use Node-RED to do something that PAC Control running on the EPIC could do.
groov View could connect to the digital I/O point directly is another option. (Add the rack as a Opto 22 I/O Unit
Thanks Bono for the info - I was asking another question. More specifically,
Where is the change detected? In the module? Via polling in the remote EPIC system? Via polling over the network?
Jim
Depends on how the polling is done.
If you are using PAC Control and have a 100msec delay in your chart, then the DI is polled by PAC Control every 100 msec.
If you are using groov View and have left the polling at the default 1 second, the groov View will poll the DI every 1000 msec.
If you are using Node-RED groov I/O node, it it hard coded to poll every 1000 msec.
If you are using Node-RED groov I/O read node with an inject node, then what ever rate you have set that inject node for.
This is why often folks use a latch. You read the latch when it suits you. That way you don’t miss the point turning on.
Thanks Beno for this great information.
I have a momentary push button where I need to read the latch. Works well.
Digging a little deeper, do any of the DI modules generate an interrupt to the processor on the latch event?
(Sorry for mis spelling your name!)
Jim
Are you using Codesys, PAC Control or Node-RED (as indicated in your OP)?
BTW, using Node-RED as your control system program is sub-optimal and if this is the case, we should talk a bit more about why and what you doing as there are some ‘gotchas’ with using Node-RED in a way that it was not really intended.
But to directly answer your question. No. There is no way to catch an interrupt even if one was generated.
Using the get and clear latch is the usual way to handle these things. But Node-RED does not have a command like that, so that is not an option… back to wondering about your original post…
I have a system that consists of six EPIC PR1 systems plus a PR2 system for Ignition Vision. The PR1 systems are at strategic locations to be close to specific subsystems (e.g. A/C & R, Electrical Switchgear, Antenna). So var all of the current tags are discrete digital events, but a few analog tags will be handled via modbus inputs from some of the systems. One of the EPIC systems, located in the Operations Control Center, receives these inputs to generate an annunciator display. The annunciator is a matrix that identifies events such as “emergency generator running” or “coolant flow Alarm” along with a horn that sounds. The operator can acknowledge the horn without clearing the fault or event indicators. The operator can also reset or clear events or alarms - problems that still exist do not clear with reset.
This annunciator is available for display at two other locations within the facility and an HMI using Ignition is being developed, also available in the OCC and at the other locations in the facility. (groov View is currently being used during system development.) The Ignition HMI will eventually be available in two additional locations elsewhere.
I have been using Node-RED exclusively. I have been concerned about generating too much traffic on the network so i do not poll over the network.
The following happens whenever an event occurs:
Node-RED on the system containing the DI
get the time of year
send a time tagged event record to an SQL database (a service in the WAN exterior to the facility)
send the event to a data store in the OCC.
Carry out any additional processing/control appropriate.
groov View
update the display based on the event
I am new at this - have not looked into PAC Control.
Thanks for your help!
If you want to stick with Node-RED and keep network traffic low, I would take a look at using MQTT.
The big advantage of MQTT is that it is report by exception so there is no polling. The data is only sent on change.
Granted, you will need to figure out how to install the MQTT broker nodes offline (like you did with the groov Nodes by installing a project that had the nodes, but no flows).
It will also mean a bit of a change to your current flows, but it should be quicker and less network traffic.
Node-RED is the right tool to use for the SQL database insert/update.
But for everything else I would move to PAC Control.
The basic version is free and there are great examples of using it in the users guide and on training.opto22.com.
