Has anyone had experience interfacing with PLCs (Programable logic controllers)? A requirement which comes up time and time again is the need to interface with an existing PLC with the goal to read/write control parameters set within the PLC. Some PLCs offer Modbus over ethernet but the only LoRa modbus nodes I know of use Modbus over RTU. I was wondering whether anyone has had experience interfacing with a PLC over LoRaWAN?
There are plenty of libraries that facilitate building a Modbus <-> LoRaWAN interface - mostly relaying certain pieces of data. As there is no guarantee of delivery of a downlink or when, I’d personally stay away from writing settings and there are downlink capacity issues to consider as well. So I’d consider your use case in detail before proceeding.
It seems like you want robust, easy to develop for hardware which can speak Ethernet. Presumably you have mains power which allows some thingts more typical battery-powered cases do not. But beware that few solutions for something like a raspberry-pi based node even try to implement the downlink side of things at all. In theory it could be done, in practice if using an embedded Linux platform (hopefully one more robust than a pi) you might consider a module that implements the LoRaWAN stack and timing on its own MCU, eg the Microchip one or the more recent offerings from others.
Or some of the ESP parts can do Ethernet; obviously some ARM MCUs can but often only in larger configurations, and embedded development gets complex especially where network protocols are involved. Debugging network issues on a small MCU platform is an order of magnitude nastier than doing so on a conventional OS.
Mostly though this would be about coming up with software that had some very good rules for bridging these extremely distinct worlds.
I have I’ve tested URSalink & Dragino RS485 devices to Modbus IO and will look at the new device from RAK soon.
What all the nodes assume is the LoRaWAN device is a Modbus master. Either by polling the PLC grouping the responses and sending an uplink. Or via (transparent mode) when an application server to sends a Modbus read as a downlink to the end device then sends a read to the PLC (slave) and then sends the response as an uplink to TTN/I. I used TTI as wanted to test Class C performance and found it acceptable for the use cases I was looking at.
None of these devices currently support the PLC as a Master which can make it tricky to integrate them into an existing systems. I posted about my my bench testing a while back I didn’t have a PLC to test the time but plan to use a Rockwell micrologic when I do.
1 Like
But that’s a software problem, isn’t it?
ie, you could take hardware which doesn’t support that, and write your own better software, and it would.
A lot of these companies like Dragino, RAK, etc are best considered as inexpensive sources of “good enough” hardware where you can replace their software with what you actually need.
Yep I done it with Node-RED and a Multitech mDOT module using the AT cmd interface this was a few years ago but it worked.
I am trying it right now with a Node Red, Pi, IO Relay Hat and Wisnode with the goal of replacing the PLC. Wish me luck!
1 Like
The issue I have with Node-RED vs PLC ladder/function blocks is there no real equivalents of control features/functions. By the sound of your use case is for actuation ?
Node Red is really only being used for replicating alarm reporting/actions. The control/scheduling portion of PLC functionality is written in Python.
Hello! Old post, I know. All good points. Completely agree. I have taken a more ambitious approach… built a LoRaWAN PLC from scratch (RAK3172 / ESP32 / 11 Relays / 2 10K IN / 1 zero-10V Out) and some pretty sofisticated software to run it as a stand alone BAS on a private network. Any of you guys still working on / interested in LoRaWAN PLCs?
Apparently not. 