Hi,
Is there a plan to support MQTT/Sparkplug B and make Tulip a MQTT client to MQTT broker?
Thanks
1 Like
Hi-
It is likely that we will support MQTT and possibly Sparkplug B in the near/medium future. We would love to learn more about what you are trying to accomplish - can you provide more details? Iād also be happy to jump on a call if that is easier.
-Pete-
1 Like
We are working on the definition of our āstack manufacturingā including Tulip. The MQTT protocol is interesting to distribute the collected OT data and merge IT and OT data. As Tulip is both a consumer of IT data and a collector of OT data, support of the MQTT protocol could facilitate Tulip integration into our futur āManufacturing Stackā. For more detail feel free to context me to schedule a call - Youri-
1 Like
A real example. We have an engraving machine that generates data as an MQTT customer (EoN). In order to ingest data in machine in Tulip, we have to create this chain :
MQTT Client -> MQTT Broker -> Kepware with MQTT Client Driver -> Kepware OPC UA -> Tulip
1 Like
Perfect, thanks! Iāll reach out; Iād like to ask a few more questions about this.
I second that request. Supporting MQTT gives us an opportunity to plug into the flow of machine data much more centrally than we can with OPC UA, which requires a presence on the individual OT networks of our various manufacturing sites.
2 Likes
@MoPositive would you be interested in discussing this as well? If so, feel free to schedule a time: Calendly - Peter Neylan
1 Like
Iām also interested in MQTT but Iām confusedā¦
Says, āNatively connect with network-based protocols such as OPC UA, MQTT, and Modbus, as well as legacy equipment.ā but this thread suggests otherwise.
If Tulip doesnāt have the capability of being a MQTT client, what does it support exacty?
Thanks,
Richard
1 Like
It would be great to discuss more about how you plan to use MQTT. If you are interested we can have a quick call, just schedule a time.
Currently OPC UA is supported directly in Tulip and in many cases customers utilize a central server that processes other sources, such as MQTT, before sending that data to Tulip. In addition, you can connect to SQL and REST APIs. For equipment, the focus has been on OPC UA but we plan to open it up to more industrial protocols this year. We will also be supporting Node-RED on our devices to enable even more flexibility. I can see how the link you sent could be misleading, Iāll talk to the team to see if we can make it more clear.
Iām aware of the Kepserver client for MQTT but I wasnāt sure if it allowed for bi-directional communication. Due to the Tulip architecture change a few months ago the Tulip IoT gateways no longer allow us to collect data from a station as āmachine dataā only āapplication dataā so we are evaluating a couple of Opto 22 groov devices for machine data collection and potentially control which can communicate via MQTT.
1 Like
I believe you can use IoT Gateway from Kepware to enable bi-directional flow with MQTT, but I havenāt tested. We do have plans to add support for Tulip Gateways and MQTT directly as āmachine dataā. In addition we plan to offer a REST API to allow you to send machine events to Tulip. This work will eliminate the need for Kepware in many cases. It would also work for the groov; although we would prefer to bring you back to the Tulip Edge devices 
.
it is essential that the data collected by Tulip gateways can be published on the Tulip platform, but also to other destinations such as an MQTT broker, a DataHub, an Analytics platform,ā¦ An open architecture based on modern, open protocols is necessary to support the digitisation of our factories.
3 Likes
Hi. Sorry to jump on an old thread, but I wanted to see if thereās any update on the industrial protocols supported.
I am hoping to connect Tulip to a device that uses Modbus RTU. Most of what Iāve read suggests we would need a central server or protocol translator to make this happen. Is that still the case?
Thanks!
Bi directional works with Kepware Gateway. We use it to write data in our Mettler scales
1 Like
As Youri indicated you can use KepserverEX but Iām not sure that makes sense for just a few machines. We use it running in Azure to collect data from over 100 CNCs which better justifies the cost.
One of your options, as you discovered, is some sort of gateway. a Modbus RTU to OPC/UA gateway would probably work since thatās how data is pulled in from Kepserver to Tulip.
A lower cost option would be an IPC or RPi running Node Red. You would need to install the modbus nodes (node-red-contrib-modbus (node) - Node-RED) and the Tulip nodes (node-red-tulip-api (node) - Node-RED) and then develop the flow (program) necessary.
3 Likes
Iām fully aligned with your post
Hey @Richard-SNN,
Since this thread was last live Tulip has released a few edge devices that might really streamline and stabilize the RasPi + NodeRed approach. They run Node-Red natively, and support bi-directional communication.
Here (Edge IO Overview | Tulip Knowledge Base - Support for Building Operations Apps) is a great overview document on the Edge IO that links out to tons of resources including Node-Red flows and demos that should really streamline the setup process.
Pete
Part of the interest is at the platform level, specifically in the context of a Unified Name Space (UNS). It would be nice to have a connector host function that allows MQTT pub/sub and not just OPC/UA. For (I)IoT native devices having to pipe everything to Kepserver to get it into Tulip requires extra configuration and another āhopā in the cloud that could be avoided. One of the biggest advantages of a MQTT native device is that all the configuration can be completed on the device and once it starts publishing it just āshows upā in our infrastructure.
Thereās also a lot of tools around MQTT that allow you to consume raw data and then republish with additional context and easy control over the topic namespace. This could allow for automatic creation of machines through MQTT subscription topic wildcards.
This isnāt possible with Kepservers ridged / structure.
We really consider KepserverEX as a method of capturing data from ālegacyā non-IoT native machines. Polling from the cloud is less than ideal and does not meet all of our minimum technical requirements.
- Edge Driven
- Report by Exception
- Lightweight
- Open Architecture
Our current process is to configure the CNC or PLC with a static IP address, which creates itās own set of problems, configure Kepserver to pull the data we want, and then configure in Tulip. This is not particularly scalable as Iām the only person working on this for the most part for 5 different manufacturing buildings and 400+ pieces of equipment.
Add the fact that IT in their infinite wisdom want to, as part of a network hardware refresh, change all the subnets globally. Now every machine, every kepserver device, and every Tulip machines will have to be ātouchedā. So not only is it not scalable, but it also creates a sustainability problem.
Being able to use MQTT in Application triggers would also be extremely useful.
At the time we implemented our Tulip pilot last year the only device available was the I/O Gateway which due to the architectural split of machine state and application data could not work the way we needed it to. This turned out to be a good thing as we ended up going with a more centralized control using two Opto 22 groov EPICs to control 41 machines in our manual finishing area.
Right now weāre abusing the telnet function in the app since itās the only way to control local devices. Because managing telnet connections can be a bit clunky within an app, our current process is to open a connection, send the string, and then immediately close the connection. However, we still end up with orphaned connections in Node Red on the EPICs and RIOs.
With MQTT, we could maintain a single connection to the broker that the EPIC could subscribe to and then publish the control commands from the Tulip App. And in reverse being able to subscribe to topics from within an app (map topics to variables?) opens up some very interesting possibilities.
Thatās not to say MQTT doesnāt have a few warts, but out of all the options out there, itās one of the best solutions available right now.
And none of this really requires SparkplugB, that would just be the icing on the cake.
2 Likes
Nice post Richard! My compagny deploy MQTT broker and we see days after days benefits to implement a broker between Device/Gateway and Tulip platform. MQTT is great for devices/machines but also great for IT solutions that publish event (new production order, new drawing version, ā¦) As REST protocol is use for HTTP connector/function and Machine API, it would be great to have MQTT for connector/functions AND machine data source
1 Like
Iām tagging @Sagar from the Connectivity team, and I can speak for Edge devices. Under the hood, weāre doing work on our Edge devices to switch from a proprietary messaging format, to something that will be much easier to connect to a broker. (*Editā¦ this isnāt to say weāre immediately going to open up the device, but weāre working on the tech stack, because we see integrating Edge devices with existing MQTT brokers as where the market is going, and there are technical benefits for us, as well). This work is actively in flight, as well as work to improve NodeRED integration with Tulip.
Iāll talk to Sagar about setting up a mini-UAC meeting thatās specifically focused on this topic.
Thereās a lot of great content here in this thread. Iāve had the time to give it a quick skim, but will read it in more depth this tomorrow.
2 Likes