I’m trying to use the ModBus code that is included with DC 9.62 (I’m using RCM2000 core modules). I’m not sure where to start with my part of the code.
The code doesn’t seem to have a routine to see if the command was sent to me, a buffer for the command from the master, or a method to ship the response back to the master.
Do I need to write my own serial routines to collect the command into a buffer, determine if the command is for me, and then call the ModBus routines? I don’t have a problem do this but I’d like a little direction.
If it helps, I’m only trying to send one digital bit back to the master and this “plc” is going to go between a modem and wireless serial radio (so we don’t have to buy an expensive PLC for just one bit. I’d like to pass on any character that comes from the master and send it out to the next device in line (I’m trying to interrupt the path between the master and slave now).
Any advice or pointers on sample code would be appreciated.
len morgan
One other thing I forgot:
We use ASCII messages NOT RTU so I’ll need to catch the command and convert from 7 bit ASCII HEX into 8 bit RTU format. I have these routines coded and working but I need the serial routines that I should use to send and receive the actual data.
len morgan
Hi, I have been using modbus on RMC3400 and RMC4300. For the most part I have been using the rabbit’s as slave TCP IP. I started with the samples from Rabbit and modified the code for my needs. I use a PC for the master or sometimes a Red Lion OIT. I am not sure what it is that you are looking for, but you should start with the samples, (they have both master and slave) and go from there. Not sure if that helps at all or not. If you have a specific question I will do my best to help, but I am kind of new to modbus my self.
Thanks for the offer of help! As I said in my original post, TCP/IP modbus isn’t an option (at least for the forseeable future. We have to go ASCII serial.
The problem I see with the samples is that they don’t explain where the data comes from. I seems to magically appear in the modbus input buffer (the code is at work so I don’t have the exact name in front of me) and the response packet is built up in a buffer but I can’t find any code to send it anywhere. In fact the documentation at the top of the file says that:
-
These routines are not meant to be called directly by user code and
-
The routines don’t really care about how the data is transported
Is there another code file or “modbus_sample.c” file somewhere I’ve missed? I’ve got the slave and master libs but like I said, they leave out the front and back end of the code.
Any help you can offer would be greatly appreciated.
len morgan
You have to follow the code back through the library’s.For example, in the sample Modbus_Gateway_Bl2600.c there is reference to modbus_slave_bl2600xx.lib. open it up and read it. As you already know, there is no magic, but sometimes the paths are a little tricky to follow. There are of course other Lib’s that are used, some you can ignore and some that you must read to be able to follow what it is that is going on.
I hope that helped.
Alan
I can’t find the Modbus_Gateway_Bl2600.c file you’re talking about. Is this part of the standard DC 9.62 release? Am I perhaps missing some code that would open my eyes to all of this?
As I said in an earlier post, I can follow the modbus_slave.lib code but where it fits in with my code is unclear. It appears to be handed a string buffer with the command already in it and it appears to already know that this is command string is intended for him. Perhaps they are making the assumption that there is only one master connected to one slave (although the picuture in their modbus docs seem to show otherwise) and so they just assume that if they got anything, it must be for them. This would certainly be the case with modbus tcp/ip since the IP address would have already determined that this is a command for this slave. All of our PLCs (the current ones) are connected together (logically) so that every slave hears every command that goes out from the master and only the one addressed responds. The other “gotcha” is that we use the ASCII protocol so the incoming command has to be “translated” into RTU format before it can be processed any further.
len morgan