# Modbus slave

P

#### Philip Costigan

Hi all I was having a look at what I wanted to do with Modbus/TCP slave and realised that It is possible to aproach this area from a completely different angle than Modbus/TCP master. I am thinking of allowing the whole LPLC io map to be referenced to the holding register Modbus map. ie 40001 to 49999. This would mean that all bits would be referenced as read only and any io_point that was assigned to modbus_tcp_slave would be driven from some external device over ethernet. It also means that only one Modbus function is required to drive all io. (Keep It Simple). All other requests would reply with an exception error. Does this sound feasable or do we want to make it complicated and assign individual points to each modbus address as required. -- Regards Philip Costigan _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

A

#### Andrew Kohlsmith

> I am thinking of allowing the whole LPLC io map to be referenced to the > holding register Modbus map. ie 40001 to 49999. > This would mean that all bits would be referenced as read only and any io_point > that was assigned to modbus_tcp_slave would be driven from some external device > over ethernet. Actually I'm working on something like this as a seperate product (485 <--> Ethernet converter) but where the RS485 ModBUS devices' addresses can be mapped into the converter's address space. It is configurable so that it can poll the 485 devices and cache the responses in order to make the devices appear to be working at Ethernet speeds. I know of a few 485-Ethernet converters but nothing that does anything like that. Regards, Andrew _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

K

#### Kipton Moravec

I have been looking at something similar. I have a bunch of controllers (166) placed throughout a semiconductor plant talking over RS-485. My customer would like them to be accessible via modbus Ethernet. I am looking at a single board computer. Advantech has one for around $300 with a 133 MHz 586, two serial ports (one RS-232 other switchable RS-232/422/485) and an Ethernet port, (and all the regular PC ports, but only 1 2-drive IDE disk connector). The RS-485 networks runs 9600 baud. So I was going to have the computer continuously poll all the devices, so when there was a request from the Ethernet side there would be an immediate response from the cached data. The SCADA system wants the data update every 5 seconds. So I got a PC-104 two RS-422/485 port card so I could handle more sub-segments since I have idle time with just one. The Advantech board also has a slot for a Disk-on-chip. They are solid state disks that plug in a 32 pin socket. You can get them as big as 144 MB. In another project where I was running DOS, a 8 MB chip was sufficient, (and only$38). In my case the controllers do not speak modbus, so the RS-485 side can work one protocol, and the Ethernet side can do the modbus. I have already used this board for a optomux interface. In this case both the SCADA and the device wanted to be the MASTER. So I put this board in between acting as a slave between both. The device wrote data the "double slave" and the SCADA system read data from the "double slave". It was pretty trivial, so I used DOS and PowerBasic. It worked fine, and they ended up ordering a total of 4 of these. It was a cheap and easy solution. Kip _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

P

#### Peter Nachtwey

My company makes a motion controller that does what you are talking about. It maps much of its memory to 400001 to 465536. We have a status area, command area, parameter area, IO area, graph data, etc all mapped to holding registers. If you make a slave device look like a PLC then the slave device will be compatible with many other devices. The only down side is that this requires a lot of tags in a WonderWare or RSView HMI. I suggest that you also write or obtain a Modbus/TCP activex control that will allow one to access you slave from Excel or Visual Basic.

G

P

M

C

#### Curt Wuollet

Excellent idea Mario, especially if we can get somebody to really explain it and document it well. As diverse IO is extremely important, anything we can do to make writing drivers approachable and painless is a big boost to our chances of gotting them done. I'm kinda waiting on this myself. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

P

C

#### Curt Wuollet

> I'll probably just do what I can while I can and when you think that your API is ready I'll try implementing it. It looks good. > Hi Philip Yes. I think that's a good plan. It will be easier to come by the knowlege to adapt it to the API than the specific Modbus knowlege and awareness you have at the moment.. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jiri Baum

Philip Costigan: > Does this sound feasable or do we want to make it complicated and assign > individual points to each modbus address as required. My (belated) 2 cents' worth... 1) From the point of view of the architecture, individual points should be assigned. The user should never work directly with the underlying point addresses - always with point names. Also, when the LPLC is to be used as a data cop, it must be able to map any input to any output. A direct mapping makes this impossible. With Mario's I/O library, this should not be too much coding effort... 2) However, I can see why you'd want to use the direct mapping at times. Make it an option? Jiri -- Jiri Baum <[email protected]> Connect the power cable, interface cable and ground wire only in the methods indicated in the this manual. It may lead to fire. -- OKIPAGE 8z user's manual _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc