Having had to deal with about a half-dozen or so PLCs in a previous job (what a loooong time ago that was...), I'm not sure that modbus was the easiest ;-) That said, I've always toyed with a few designs that would get it working on platforms other than Windows (which is where I was at the time - job requirement, not personal choice ;-}). Anyway, my suggestions would be:

Package namespace: PLC::*. e.g., PLC::Modbus. Alternately, SCADA::Driver::PLC::* - depends on whether someone will want to do a full SCADA suite here or not ;-) I'd go with PLC::* first, and if someone wants to use SCADA::* later, they can have a driver that merely inherits from your PLC driver.

I'd also suggest, if you can, getting a hold of a second PLC with a different protocol. By looking at more than one protocol type, you may be able to better abstract what you're doing, making your objects a bit more higher-level. Think how bad DBI would have been if it were only designed for Oracle, for example.

So, what I'd want to get in here, in my ideal world that is ;-), would be methods that:

• Created any type of PLC::* object (e.g., PLC->new('driver:Modbus'))
• Registered memory points to request asyncronously - this way, your driver could optimise memory points that were close together into a single request of the PLC. Sure, you may be getting memory that you don't care about, but you'd reduce overall traffic by making fewer requests of the PLC.
• Requested a given memory point immediately. Opposite to the above is a synchronous request for a single data point. This should be documented as "try to avoid" as it will slow down most applications.
• Request for changed data. Each registered data point would be remembered (probably in a hash), but there'd be a separate hash or list or whatever to track data points that have changed. That way, the requestor could focus on only values that have changed. Each time this is called, you'd send back a list of tuples of the form ( [ $datapoint => $value ], ... ), not necessarily sorted, and then it would clear the changed hash. In a non-threaded model, this would also actually send out a single request on the line, wait for its response to return, parse it, etc.
• Set into threaded-model where the requests are sent out every $n seconds (where $n could be fractional - user-specified). This may be difficult to get going, so you may want to wait on it ;-)
• Request for a particular registered data point. If the data point isn't registered, this would be an error. If the data point just simply hasn't been requested yet, put that request to the front of the queue, and send the message (where you'd then potentially get more than a single data point back). Also clears that point from the "changed" list.
• "Peek" at data points/changed list. That is, get the values back, but don't clear the changed list.

I've a need to look at a non-*nix, non-licensed MODBUS serial driver/script and have located the one that suits the need at http://www.modbus.pl/downloads.htm . BTW - there's a MODBUS tcpip script there as well.

I'm not a perl guru, but have written a bit of code and managed a bit of code in a Linux (RedHat enterprise, was-Mandrake, and others). I've never loaded perl on a Windoze system until this week. I'm totally (well - at least significantly) confused with CPAN and compilation errors. Rather than posting errors, I'm wondering if there is a place to find general instructions for implemeting Perl on/in an XP environment. I've downloaded Micro$ofts compiler, so I can now compile, but still having problems. I'd rather know how to fish at this point.

Thanks!