I have Control 3/2/08
I have Control! :-).
I've made lots of progress on the PIC software end after finishing the layer 1/2 area of the modbus protocol stuff last week. As per the software page you can see I've got functions 01, 02, 04 and 05 going.
In the scheme of things that's enough to actually do some work, so I slapped some more hardware on my test RTU, and I'm in business. As per Fig 1.
Fig 1.
I've made the RTU code semi-modular so I can add in I/O functionality relatively easily. To that end I stuck a junk-box Dallas DS1820 (Now Replaced by the Maxim DS18S20) on a spare pin on the PIC and added it in on input register 01 (Why 1 and not 0 ? Dunno).
I had the PIC code for driving this from an old project using one of my very non-standard PLC's I did when I ran Ohmark Electronics. I copy'n'pasted the code for the 1820 in, changed the timing for 20Mhz and I was reading the temperature of my workbench in no time flat.
I put a small light bulb on one of the relay outputs, and a fan on the other and wrote a (very) quick'n'dirty thermostat program in C. With the DS1820 sitting right on top of the light bulb it clicks on and off quite nicely, aiming for a setpoint of 27C.
Fig 2.
Figure 2 shows just how wonderful this all is. The DS1820 can be see roasting on the open light bulb, and the fan to the left kicks in if it overshoots by too much. Kinda pointless, but gives me a simple test-bed for the software at both ends.
I even got a little bored, added a csv log output to the code and got the purdy graph below after sticking the data into Open Office:
Fig 3.
On the PC front so far I've signed up at http://launchpad.net so I could log a couple of minor bugs in libmodbus, and re-learned a fair bit about 'C'. Given that the last time I did anything of note in C was using Borland Turbo C 2.0 in about 1993 I think I'm doing OK.
Commercial units that don't comply with modbus standard
Two interesting discoveries I've made along the way is that many commercial modbus RTU's do not fully or correctly support the command set, and some do not meet the comms spec for modbus over serial line. (Layer 1/2)
If you're working on any project it often pays to see what other people have done before you, but it was a surprise to find some (very) expensive commercial modbus RTUs which did not appear to be compliant with the standard.
Function 01 and 02 which read Coils or Discrete inputs can, in the standard, read in any number of bitwise inputs/coils starting at an arbitrary bit number. I downloaded PDF RTU manuals from a number of commercial vendors, and found that they specify these commands to only work with a start address of 0, or multiples of eight or sixteen bits.
Sounds like lazy programming to me, it only took me an hour or so to figure out a way of handling the odd start address and pack any range of bitwise inputs into the modbus PDU.
On the hardware front I found two vendors who sell 'modbus' RTU's that do not support even parity, which is the required default in the standard.
I can't see the point of a robust open standard if vendors can say they make 'modbus' modules that are not compliant with the standard. I've emailed one of the folks at modbus-ida to see if this is an issue for them as well. If it is I might name-and-shame the vendors concerned. :-).