• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Modbus TCP Connection via RTE Ethernet Ports
#11
505 Wrote:Second, I would like to make this same request for the NetIOT platform. The NetIOT is more attractive for our solution because of the Node Red, MQTT, etc pre-installed. But with no access to the docker system, I am stuck with never having Modbus/TCP as an option on the RTE port which is a must have for our option.

We decided for the next big software update planned for end of August to implement Docker on ALL netIOT Edge Gateway Platforms. This gives customer more flexibility on all gateways as they are used to on the biggest netIOT Edge Gateway only till then. But there is a drawback. The industrial network controller netX is single resource on ALL platforms will be occupied by preinstalled Node-RED on these Edge Gateways. This means the new Docker function will allow you to add your own software on all gateways in future, but you will never succeed in running the ethernet supporting firmware instead of the fieldbus EtherNet/IP or PROFINET. You can disable Node-RED as a service ... yes ... then you can access the netX chip yourself with own docker images.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#12
505 Wrote:My request is this. First, would it be possible for you to create a Node Red container for the NetPi hardware similar to what you described in the steps in this post. Or possible create a Node Red deployment that already includes the standard Lan firmware load for the RTE port, or even if it was selectable as another option along side Ethernet/IP and Profinet. That would be ideal.

Chris a I have problem in doing so. netPI is an open platform for everybody. The examples provided today are 24h available samples/support for the community to teach them creating own containers. We have now over 400 customers all over the world. If everybody would come to ask for his personal container then Hilscher Docker Hub repository would grow and grow and nobody is there to support all those images. I could not do it. Especially in your case all you need is already there and available in open source in two separated containers. You just have to add one and one together as described in a post before. For a professional use - netPi initially was made for - you have to create an own Docker registry with your own images anyway and then you dig into details anyway ... don't you agree?
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#13
Hi Armin,

I can agree with your point of not becoming a custom container programmer for everyone. For me right now, I am just getting started with the learning of how to work with these systems, so I have a lot of learning to do before I am able to make my own image. My real issue is that the NetPi and NetIOT devices lack UL certification on them. From my discussions with our Hilscher representative, there are no plans to provide the certification. This means that we cannot move forward with this device for the US market which is too bad, because I really like the platform other than a few short comings like the Modbus/TCP problem. But I think that can be fixed with the right custom container. Therefore, I was hoping to have you build the image for me to prove that it can be done and if so, push more for the UL certification. Again, I see your point with the development. So I'll ask a final question though, why not just add the Modbus/TCP firmware stack as an option as the NetX51 chip supports the stack already? Is that possible rather than using the open ethernet firmware instead?
  Reply
#14
Hi Chris,

we are in a quote phase with the manufacturer of the netPI to get a UL certificate cULus(UL61010-2-201). After we have the quote we will trigger UL.

Then a word to the Modbus/TCP firmware and the examples. The three examples we provide on github are the original examples customers are gettin when they are becoming a netx51 chip customer and are designing their own netX host platforme. So it was no work to put them on github in the latest revision.

Unfortunately we brought the source code for Modbus/TCP not into the same c-coded format as we did that for the three other examples. Currently it is a C++ coded version from year 2011 and would need a reengineering. Next point is even if we have a netX51 chip running on netPI this is a different type of hardware and would need the development team to rebuild a new branch for this netPI/netX51 combo.

And since other customers want to run CODESYS PLC with Raspberry PROFINET,EtherNet/IP, EtherCAT Master Stacks over netX TCP/IP Ethernet and Node-RED Modbus TCP Stacks exist already ... it was easier for us to provide a TCP/IP Ethernet over netX than to dig into details of Modbus examples.




You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#15
516 Wrote:So I'll ask a final question though, why not just add the Modbus/TCP firmware stack as an option as the NetX51 chip supports the stack already?

By the way which function do you exactly need? Modbus TCP Master or Modbus TCP Slave?
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#16
Hi Armin,

Thank you for the responses. I am looking for a Modbus TCP Master. I know that Netx51 is a slave only device. But as I read the firmware list for the Netx51, the ModbusTCP was only listed as Open Modbus, not necessary client or server. So I was hopeful that it could be a master also.

My opinion is that if we add these into a control panel, the Ethernet/IP and Profinet Slave would mean that the device in the panel would already have to "know" about the presence of the gateway and have the network connection data predefined. IMO, this is very limiting because it would be much more preferable to be able to add the gateways separately and then have the gateways setup to request the data without the need to modify PLC code. This does work in the current netIOT device, but since you have to share the port that would be used for the cloud connection, your IP address scheme is very limited, which is why I am pushing for the RTE port to be used.
  Reply
#17
but with netPI RTE, it already has one TCP-IP port avaialble , with this Modbus TCP communication can be done.
  Reply
#18
Yes this is correct. Even with netPI CORE 3 having a single Ethernet port only a proper Modbus TCP communication can be established. An RTE port like with netPI RTE 3 is not necessary at all.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#19
We have been updated the netx-programming-example container under https://hub.docker.com/r/hilschernetpi/n...-examples/. Now also a Modbus TCP server example is available. And if you read the API manually carefully you can read how to modify the example and the initialization phase that it also supports Modbus TCP message based client functionality.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Fieldbus Ports not working Schoko 7 45 October-29th-2019, 08:59 AM
Last Post: Armin@netPI
  normal ethernet port using for Profinet MGharat 4 35 August-7th-2019, 10:39 AM
Last Post: hannes
  [SOLVED] Slow network connection Andi 5 31 May-22nd-2019, 05:16 PM
Last Post: Armin@netPI
  RTE3 Use real time ethernet as "normal" ethernet interface hannes 50 308 May-9th-2019, 04:28 PM
Last Post: Armin@netPI
  niot-e-npi3-51-en (RS485 <-> Industrial Ethernet) merklethomas 6 59 April-26th-2019, 01:38 PM
Last Post: Armin@netPI
  USB/Ethernet adapter slos 4 52 April-8th-2019, 09:11 AM
Last Post: slos
  IP Realtime Ethernet michu252 7 324 August-21st-2018, 10:41 AM
Last Post: Armin@netPI
  [SOLVED] Modifying ports after container is being added. SteveO 2 132 May-9th-2018, 02:39 PM
Last Post: SteveO
  3 Network Ports possible on NIOT-E-NPI3-51-EN-RE? yulian 7 199 April-3rd-2018, 02:57 PM
Last Post: Armin@netPI
  NodeRed Modbus Flow iotuser 1 83 March-27th-2018, 11:14 AM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)