Modbus

[Embedded]

Fixstuff555 Wrote:

Another hardware support option. And this is huge. I come from an industrial hardware background and have a ton of experience using Modbus TCP clients and servers. This protocol uses ethernet and is an open standard, the source code can even be downloaded somewhere pretty easily. Your network client and server seem pretty limited to me, since its only string based. A module for both Modbus TCP Client and Server would be HUGE. This ties your product into virtually every industrial PLC and controller on the market today. I actually happen to have a ton of old buscouplers and IO slices from several manufacturers just sitting in my parts bins. If you had these modules available, hardware like that could be easily integrated into a flowstone project for distributed IO. This is really low hanging fruit in my opinion, since its open source, is very established in the market as a protocol, and would give Flowstone some real legs with industrial hardware folks.

FYI the FlowStone Network client also supports hex stings as well as text stings, so you can easily communicate using Modbus TCP! (see attached file - writes 1 then 0 to Coil 00).

You can test this using a Modbus Server Emulator like this one: http://www.plcsimulator.org/

Plus more info is available here: http://www.simplymodbus.ca/TCP.htm

[Embedded]

Here's my new Modbus TCP Client Test program.

Now included are all of the Function Codes to send and receive all types of data.

To test I used a Free Modbus Server App. http://www.plcsimulator.org/

Works a treat

Enjoy...

Modbus.png (116.52 KiB) Viewed 38596 times

[fixstuff555]

Thats is really great! Now I get to play with it to see how it does!

[fixstuff555]

Really great job with that!. It looks like it all works. I typically use the holding registers, with the read and write multiple register commands (3 and 16). Those work great for multiples as well as single registers with a length of 1. Most industrial hardware usually only supports a couple Modbus commands. You did a really great job, I can use that with my projects very easy. You single handedly expanded the available IO for Flowstone by about two orders of magnitude with this great module. I can see this cleaned up to be a very, very useful primitive. I may even post a video later on Youtube showing this hooked up to an industrial modbus buscoupler. With a bit of cleanup and a nice GUI, you could build a nice little machine with this btw. Awesome work!

[Embedded]

Thanks for the feedback.

Have you any suggestions how a Modus GUI should look?

It's my first time exploring Modbus so any help would be appreciated.

[fixstuff555]

Absolutely! A good GUI for this modbus feature would be to keep it sweet and simple to make it easy to incorporate into other code. You basically need a couple things. The first is, keep the module simple. By that I mean build separate modules for the type of IO you want to work with. I'll start with what I believe is the most useful. The read multiple registers command (modbus command 3) and write multiple registers command (modbus 16) are the most useful. You could base most or all of your modules around these two commands, and be able to talk to 99% of the modbus devices out there. Stay away from the other modbus commands except the most basic for a while, since most manufacturers simply won't bother with implementing them. Next, you will need two types of each module,a master(client) and a slave(server). The client provides the polling commands, the server simply listens for those polls, and provides data back to the client when asked. A great analogy I heard one time is the waitress/customer analogy. The waitress is the server - she takes the orders and provides the food (data). The customer (client) is the requester (master). It asks the server for data, the server responds. Anyways, for basic setup inputs, you will need to have a starting register input, a number of registers input, IP address input, single or continuous scan input. Don't worry about coils or discrete inputs - keep everything based on 16-bit words, and break it out to bits when needed. You could initially build a simplified version that doesn't use an array for the data, but keep it at say 10 words. Keep it simple, simple, simple, and a lot of people will use it. Make it really complicated to set up and use and nobody will be able to figure it out. Build the basic blocks right, and you could easily combine them into a complicated block later. A good first goal should be two block types. A Master and a server, with say 1-10 words in and out. The Master would have 1-10 words IN and 10 words OUT. Same for Server. This would allow for a nice ethernet pipepline between flowstone nodes for testing, as well as provide the interface to talk to 3rd party stuff like the Modbus simulator you linked. By the way, that simulator believe it or not is HEAVILY used. I've used it for years, and everyone I know has used it as well. Its the first tool I use to evaluate Modbus on new controllers and stuff. There are some weird quirks with it - particularly the floating point display, but overall it's a really good tool.
I'm loath to include this initially, but it is really important eventually, it's a watchdog input. If you lose a connection between the master and server, you need to have the ability to select from two behaviors. 1 is to freeze the outputs from the other connection, 2 is to zero the outputs from the other connection. Of course, a timer is needed for the zeroing part for intermittent connections. This watchdog can be omitted initially to get the modules up and running, but eventually this is useful to have, especially if you are running something remotely. You wouldn't want and output relay staying on if you connection was lost. I'd love to collaborate further with you if you want. If nothing else I could help you test them out with other hardware also. Sorry for the long post.

[Embedded]

OK, here's the next version of the Modbus Client as you suggested.

In this version, I have simplified the UI to just write to 10 registers, with an address offset. The Hex values can by typed on screen or be sent to the module as inputs.
The read registers is similar with an offset etc. but this can be polled to automatically keep reading the given registers. The polling frequency can by changed using the provided knob. The read values are also sent out of the module as well as displayed on the screen.
There are also edit boxes for the IP address and port number.

I've not spent any time on the look of the GUI yet whilst we sort out the functionality.

What do you think?

[fixstuff555]

The reading portion:
The reading is pretty much good to go. The polling works, you type in the starting address and the numbers populate the integers just fine.

The writing portion:
A couple issues. The first is parsing the input numbers. If the string is entered manually, for example, a "0004" for a number "4", the messaging works. If the number is entered in the INT input block, the string comes out "04" and doesn't send properly. Not sure if there is a block or object for this problem.

Is it possible to open up another client in flowstone? If so, then each function code could get its own message, and then maybe they wouldn't step on each other. Each server can have up to 10 connections. This is set up for 2 connections to each client - 1 for reading, 1 for writing. You can use one like you have, but you have to sequence the reading and writing through the single client.

Is multiple clients in flowstone only possible with Pro? If so, I guess we should stick with 1 and make that work. If not, then splitting them would make things easier to deal with. I think having a read object and a write object would be better if thats the case.

Overall, this looks pretty good. The reading section is awesome, and I could really crank that polling up. Most industrial controllers can poll at about 10-25ms, and this one I was able to crank down to about 25ms (40 reads/second). I think the writing is almost there, its just the input parsing that really needs fixing.

If you are able to do two clients, then even being able to poll separately would be nice. You could set the reading at one rate and the writing at another rate. To only write on change, I simply tied each input to the same write trigger.

[Embedded]

I forgot to test the inputs - duhh

Anyway the inputs are now working correctly, and it seems no problem to have two or more clients so I have done as you suggested and split the read and write up. This does simplify things quite a lot as far as dealing with the error messages etc.

If the Write Client times out then the fist click on the write re-opens the connection and the second send the data.

[fixstuff555]

Ooops. This file is corrupted... Could you repost please?