Well I don’t know what Modbus TCP/IP is, or what Digital IO is, although a quick search tells me the former is a protolcol for supervision and control of automation equipment.
What IP address will the target devices have and how do you set it? What port do they listen on? What research have you done? What documents have you studied to understand the protocol and how it applies to the devices you have? I see also there’s a Wikipedia article on Modbus.
Thanks for your response.
I shall try & answer some of your questions based upon my current understanding.
Modbus TCP/IP is basically MODBUS over IP. The Digital IO is nothing but remote IO device which communicates using Ethernet port. The standard port for Modbus TCP/IP is 502. The communication needs to take place something similar to as explained in pyModbusTCP · PyPI.
I am not aware as to how the communication protocol works, since till date, I have used different softwares such as DaqFactory or Matlab which have inbuilt modbus TCP/IP libraries. However, I find there certain limitations within these softwares with regards to ease of use, because of which I want to use Xojo for this new project related to Factory Automation.
If someone can develop standard plugins for Modbus TCP/IP & Modbus RTU, I am even willing to buy them, since I believe this shall help increase the capability of Xojo and thus its reach in Industrial Automation.
Perhaps there is a different way to approach it.
I have tried to understand modbus but can’t quite get my head around it. It also seems like it is an outdated standard. With the speed of tcp/ip communications there are many methods to transfer data. I wrote my own building automation software using xojo and automation direct arduino compatible plc’s. I use xml on both client and server and it works seamlessly not to mention a lot easier to understand and maintain.
Here is the write up on my project.
There is another more secure standard to replace MODBUS but the sheer volume of legacy hardware out there means MODBUS will be around for a very very long time yet.
Probably longer than Xojo, frankly.
NB if you don’t know what an industrial PLC is for, think coal or nuclear power stations, steelworks, oil and gas rigs, mines. Trains, process plants, manufacturing facilities for food, fertiliser plants, automatic bagging and pallet machines… Things that tend to go “bang” in a big way in milliseconds.
Particularly safety systems where human life is at risk if there are hazardous undetected failure modes.
NB if what you are playing with is safety-related, ie someone could be harmed if your solution screws up, do not use Xojo, not even for supervisory monitoring and especially not for control. Please obtain and read the relevant standards in your country concerning industrial safety and programmable devices. In UK or Europe EN50126, EN50128 and EN50129.
Aduino, Pi, PIC and similar are tinker toys in comparison.
That is your opinion. Maybe you don’t know what makes a PLC go. They all have Micro-Processors and are ‘programmed’. The devices from Automation Direct are Industrial. Because they are programmed with the Arduino implementation of C++ does not make them a ‘tinker toy’.They are just as industrial and robust as any other brand available and they meet all necessary standards. I have had a lot of experience with many brands of PLC’s they all do the same thing. The P1AM line is just more versatile. If you know what you are doing with Xojo it is as good as any other computer language.
And another thing Modbus is not really a standard because almost all of the manufacturers have their own implementation and it is very obscure.
Xojo supports socket programming, and you can use it to establish a TCP/IP connection to your Modbus device. Use the TCPSocket class in Xojo to create a socket connection. Modbus has a well-defined protocol. You’ll need to implement the Modbus protocol to read and write coils and registers. Refer to the Modbus specification (Modbus Application Protocol Specification V1.1b) for details on how to structure Modbus messages. Using the socket connection, send Modbus messages to the device and receive responses. Parse the responses according to the Modbus protocol.
Thanks for the inputs. I shall definitely try creating a TCP Socket Class and then write instructions to initially read and then write to a connection.
I shall try if possible to write a short code as well for everyone to refer, once i succeed with a test connection.
We are using Modbus TCP in Xojo to control a motion picture film scanner. Just use LibModbus - works great, no need to deal with sockets or formatting.
In our case, we basically created a Xojo class that exposes all of the fuctions of libmodbus that we need, to our application. On launch, we create an instance of that class and the app automatically connects to the MCU. Communicating with it is as simple as:
In this case, it writes a “1” to register 12
We don’t have a need for all of the functions of the library, which is why I haven’t made my Xojo code public, since it’s incomplete. But getting it set up was pretty easy. Since we have two controllers, one for the transport (motors, etc), and one for the imaging tools - the LEDs, and the camera/lens linear stages, we create two instances on startup: TransportController and ImagingController. Each has its own set of registers and it’s lightning fast.
If somebody wants to finish this off I can toss the Xojo code up on our github and give them access to it.
I just took a look at my code and it’s a bit of a mess, since it’s so specific to our implementation. but with a little time I could clean it up. It also has some methods to support reading from and writing to 32 bit registers (which are split across two 16 bit registers), thanks to help a few months back from folks here. My implementation only includes the code for Modbus TCP, but serial communications are also supported by the library, and implementing that shouldn’t be hard, I just don’t have time or the equipment to test that, so I’d leave it to someone else to do that part.
Modbus has turned out to be a great way for us to communicate with the scanner, after a few attempts at developing communication protocols that all had issues. It’s been completely flawless for us so far.