Arbitrary Bi-directional Communications from Tulip Player via (ab)using Telnet + NodeRED

Show and Tell
, ,
1

We’ve have some interesting use cases we’ve used (abused?) the telnet feature of Tulip Player + NodeRED to implement interfaces required by Operations.

NOTE: We are using arbitrary NodeRED servers so we’re not dependent on the EdgeMC device.

  1. Machine Interlock - Production orders must be logged in before the operator can turn on the equipment.
  2. CNC Program downloading - Once the production order is logged in, the correct validated CNC program will be downloaded to the equipment.

This is accomplished by sending formatted text from Tulip Player to a NodeRED tcp connector. The easiest way I’ve found to ingest the information is by sending comma separated text and then using a csv node to turn it into a native JavaScript object.

image

In the case of #1 we pass the asset number and true or false as to whether the interlock should be engaged to a Opto22 groov EPIC or Rio (fantastic devices!) which have NodeRED built in. The message is routed to the appropriate digital I/O output, and then a response is formatted and sent back to the Tulip Station as a pop-up message.

Here’s a demo workflow which just immediately responds:

image
image934×123 8.59 KB

image
image986×678 27.7 KB

For the actual machine interlock the groov devices have I/O specific nodes that I would route a msg.payload status of true or false to change the state of the I/O.

The key to getting this working correctly is you have to open the telnet connection and send the message by whatever trigger you need (on step enter, or a widget) but not close the connection yet, otherwise it won’t wait for the response. Then you add a device trigger to receive the message and then close the connection.

For #2, the NodeRED server is currently on my work laptop but could just as easily be on a cloud server. Here I’m using NodeRED to create a client interface from Tulip Player to our CNC Program server or DNC, Cimco. I have installed the client executable on my laptop as well so I have direct access via a NodeRED exec node.

image
image873×673 71.2 KB

This one is a bit more complicated but turned out to be quite robust. Basically I send a comma separated string of the asset (machine) that needs the program and what program needs to be sent. I format the proper command line options and then run the client with said options.

The output is captured as well as the exit code where I use a switch node to route to the correct response message indicated success or failure, and what the failure was.

image
image986×678 24.8 KB

Feel free to ask for more details but I think this is a long enough post for now.

5 Likes
2

Your example with the DNC is very interesting. I had a question about loading the program into the PLC. Does Node-Red load the program into the PLC (via Opto API for example) or do you trigger the action from Node-Red which is executed by the DNC software?

3

And MQTT will be better communication protocole compare to TCP/IP. Will be nice is Tulip can be a Pub/Sub MQTT client : Publish message from trigger and subscribe to topic in app.
Last I’m agree with you, Opto22 have great product and Edge vision.

4

Yes, the program storage (and revision control) is completely controlled by Cimco so I’m only using nod-red to initiate the download using their DNCMaxCrtl client.

5

Absolutely, that would be the preferred method if it was available.

We are actually using MQTT to capture machine state data for non-PLC machines (or machines where we can’t talk to the PLC) via Kepserver’s MQTT Client driver.

This allows us to capture machine state data from manual finishing machines that use VFD controllers. Most of them seem to have a way to capture if they’re running and even the speed they’re running at via a 0-5V or 0-10V output which we’ll be recording using an Opto 22 groov EPIC, but that’s another post :slight_smile:

2 Likes